ReleaseProcess

Release Process

We denote versions with x.y.z where x is the major version, y the minor version and z the revision number

1. Create a branch release-x.y.z, and check it out
2. Update CHANGELOG.md to include the new release
   1. Release Number
   2. Date
   3. New Feature(s) if any
   4. Bug(s) Fixed if any
3. Check the version number in _build\build.cs
4. Open a command line and run "build". This will do the following:
   1. build the code
   2. run unit tests
   3. zip the runners
   4. create nuget packages
   5. Unzip the files in the deploy folder by running "unzip x.y.z"
   6. Test the runners
      1. testRunnerCmd.cmd x.y.z
      2. testRunnerMsBuild.cmd x.y.z
      3. testRunnerPowerShell x.y.z
5. Run DeployArtifacts.cmd x.y.z - this will
   1. Run "DeployOutput.cmd x.y.z" - this will
      1. Generate outputs with new version (this is already done by the "test the runners" step)
      2. commit the changes to the repository
   2. Push the nuget packages to nuget gallery by running "DeployToNuget x.y.z"
   3. Upload the chocolatey packages to chocolatey by running "DeployToChocolatey x.y.z"
6. Push the release-x.y.z branch to GitHub
7. Merge to the master branch
   1. Create a pull request from the release-x.y.z branch to the master branch
   2. Wait for the continuous build to be green
   3. Merge the pull request
8. Create a release on GitHub
   1. called vx.y.z
   2. with release notes
   3. tag it with 'vx.y.z' on branch master
   4. Upload file "$/deploy/pickles-RUNNER-x.y.z.zip" for each RUNNER to the release
9. Remove ready-to-be-released label from each issue/pr that is released, and add a "released in version x.y.z" comment.
10. Tweet using @PicklesDoc

PS: the "Release" branch is only used for historical purposes. We used to put releases on their. These days, we tag the master branch with the release.