Release Procedure

This documents the procedure that should be followed when releasing a new version of the Chocolatey Community Validation project. Most of the steps outlined in this document can be done by anyone with write access to the repository, with the exception of the built artifacts that need to come from a Chocolatey Team Member.

For the steps requiring a Chocolatey Team Member, reach out to one of the team members associated with the repository and ask them for the package artifact once a tag has been created.

[x] Update the issue title with the new version number of the release.
[x] All tagged releases of Chocolatey Community Validation should come from:
- [x] The master branch for a normal release, or
- [ ] A **support/*** branch if doing a backport/bugfix release for an earlier supported version, or
- [ ] The hotfix/ or release/ branch, if a beta package is being released, or
- [ ] The develop branch, if an alpha package is being released.
[x] Before moving forward, run build.bat locally, to verify that everything builds as expected.
[x] Make sure all issues in the upcoming milestone have only one type label associated (A type label would be labels such as Feature, Improvement, Enhancement, Bug Fix, etc).
[x] If the GitHub milestone issues are still open, confirm that they are done before moving on. If they are in fact done, apply the Done label and close the issue.
[x] Update the GitHub milestones description if there is a need for any custom words that should be part of the release notes.
[x] Run the following command to generate release notes .\build.bat --target=releasenotes
- [ ] NOTE: If doing an alpha/beta release, don't run this step, instead generate the release notes manually. GitReleaseManager uses labels and milestones to generate the release notes, and therefore won't understand what needs to be done, especially when there are multiple alpha/beta releases.
- [x] Before running the above command, make sure you have set the environment variable GITRELEASEMANAGER_PAT to your own access token. This can be set through PowerShell with $env:GITRELEASEMANAGER_PAT = "<token>". This token requires access to the labels, milestones, issues, pull requests and releases API.
- [x] This will generate a new draft release on GitHub - the URL to the release should be output from the above command.
- [ ] If doing a release from a develop, support, release or hotfix branch, verify that the target branch for creating the new tag is correctly set, and we are not tagging against master for this release.
[x] Review the generated release notes to make sure that they are ok, with appropriate names, etc, make any changes if needed.
[x] This step should only be done if this is NOT an alpha or beta release. Merge the hotfix or release branch into the master or **support/*** base branches.
- [x] git checkout master OR git checkout support/* (NOTE: If you do not have access to push to the master branch, ask a Chocolatey Team Member to be granted bypass access).
- [x] git merge --no-ff <branch name> i.e. hotfix/4.1.1 or release/4.2.0, whatever branch you are working on just now.
[x] Push the changes to the upstream repository, and to your fork of the repository.
- [x] git push upstream - here upstream is assumed to be the above repository.
- [x] git push origin - here origin is assumed to be your fork on the above repository
[x] Assuming everyone is happy, Publish the GitHub release.
- [x] This will trigger a tagged build on a private CI system. NOTE: Contact a Chocolatey Team Member about sending you the package artifact once it has been built if you have no access to internal systems.
- [x] Save the package acquired from the internal systems, or a Team Member to a local directory on your local system.
[x] Verify that the package can be installed, the extension is loaded and that it can be uninstalled.
- [x] Run choco install chocolatey-community-validation.extension --source="'C:\testing'" (replace C:\testing with the location you sawed the package to) and ensure that it successfully installs (use upgrade if it was already installed).
- [x] Create a new package using choco new packageName and then attempt to package the file using choco pack packageName.nuspec. Verify at least one rule validation with the prefix CPMR is outputted.
- [x] Run choco uninstall chocolatey-community-validation.extension and verify the package was successfully uninstalled.
[x] Go back to the releases page, and upload the package artifact chocolatey-community-validation.extension to the release.
[x] Push or ask a Chocolatey Team Member to push the previously uploaded artifact to the Chocolatey Community Repository (Wait on confirmation that this has been pushed, and is pending moderation before moving further).
[x] Move closed issues to 5 - Released with the Done Label.
- [x] NOTE: This step should only be performed if this is a stable release. If an alpha/beta release, these issues won't be moved to released until the stable release is completed.
[x] Use GitReleaseManager to close the milestone so that all issues are updated with a message saying this has been released
- [x] NOTE: This step should only be performed if this is a stable release. While on alpha/beta release we don't want to update the issues, since this will happen in the final stable release.
- [x] Before running the below command, make sure you have set the environment variable GITRELEASEMANAGER_PAT to your own access token. This can be set through PowerShell with $env:GITRELEASEMANAGER_PAT = "<token>". This token requires access to the labels, milestones, issues, pull requests and releases API.
- [x] Use a command similar to the following tools\GitReleaseManager.0.11.0\tools\GitReleaseManager.exe close -m 0.17.0 --token $env:GITRELEASEMANAGER_PAT -o chocolatey-community -r chocolatey-community-validation. This should become an automated step at some point in the build process.
[x] Once the package is available and approved on Chocolatey Community Repository, announce this release on the public Discord Server under the channel #community-maintainers (There is currently no format for this, but ensure a link to the release notes are included). (As this was the first release, we made this release announcement before it is approved)
[x] Next up, we need to finalise the merging of changes back to the develop branch. Depending on what type of release you were performing, the steps are going to be different.
- [x] If this release comes from the master branch:
- [x] git switch develop
- [x] git merge --no-ff master
- [ ] There may be conflicts at this point, depending on if any changes have been made on the develop branch whilst the release was being done, these will need to be handled on a case by case basis.
- [ ] If this release comes from a **support/* branch, the following steps should be completed if changes made in this release need to be pulled into develop**. This may not be necessary but check with folks before doing these steps:
- [ ] Create a new branch, for example merge-release-VERSION-change from develop.
  - [ ] git switch develop
  - [ ] git switch -c merge-release-1.2.3-changes
- [ ] Cherry-pick relevant commits from the release into this new branch.
  - [ ] git cherry-pick COMMIT_HASH (multiple commit hashes may be added).
  - [ ] Repeat until all relevant commits are incorporated.
  - [ ] If all commits since the last release on the support/** branch should be included, you can select these all at once with `git cherry-pick PREVIOUS_VERSION_TAG..support/` (selecting the previous version tag and correct support/*** base branch that the tag comes from).
- [ ] Push this branch to you own fork of the repository, and PR the changes into the develop branch on GitHub.
[x] Delete the hotfix or release branch that was used during this process
- [x] NOTE: This steps should only be completed if there are no plans to do subsequent alpha/beta releases for this package version.
- [x] git branch -d <hotfix or release branch name>
- [ ] If the hotfix or release branch was pushed to the upstream repository, delete it from there as well.
[x] Push the changes to upstream repository
- [x] git push upstream - here upstream is assumed to be the above repository.
- [x] git push origin - here origin is assumed to be your fork off the above repository
[x] Update the information in the Chocolatey Community Packages repository
- [x] In the .appveyor.yml script, find the mention of chocolatey-community-validation.extension and update its version to the released version number.
- [x] Submit a PR with the changes made.

chocolatey-community / chocolatey-community-validation

Release: Chocolatey Community Validation v0.1.0 #24

Release Procedure