Preparing a Release

Versioning

Starting with release 4.2 we are using following versioning scheme:

For a version X.Y.Z

• Even minor number Y: Official stable release (like 4.2, 4.4 etc.)
• Odd minor number Y: Development build, usually automatically pushed to VSIX Gallery. Example: 4.3.x are the development builds after official 4.2 release, finally forming the next 4.4 release in future.

Steps to update the version in solution:

1. Open UpdateVersion.2017.ps1 in solution's root directory and update version number in $version and release notes link in $releaseNotesLink variables.
2. Save and run UpdateVersion.2017.ps1 with solution's root directory as the working directory.
3. Rebuild solution.

Release Build

We build the release binaries using AppVeyor. Our AppVeyor build job automatically builds the release branch as soon as it's pushed to a certain submit in main repository. In opposite to master branch, which contains the latest development stage of source code, the release branch marks the code base of latest release.

1. Decide which submit the release has to be based on and merge everything up to it to release branch.
2. Update the solution's version number (as previously explained in Versioning) and submit the changes made by template generation.
3. Push branch release to main repository.
4. Wait until AppVeyor build job has finished (it also runs all tests on this release).
5. Take artifacts of release build job (VSIX, analyzers NuGet package, library NuGet package) to upload them at appropriate places.
6. Checkout master branch again.
7. Update the solution's version to the next development build version (example: 4.3 after having released 4.2), submit the changed files.
8. Push master branch to main repository.