Releasing Rubberduck

Rubberduck has a two-tiered release model.

• We're releasing every build on next as a prerelease automatically.
• We're releasing builds from master as a "stable"/"green" release.

Appveyor, our CI does help us a lot with that.

Pre-releases

Prereleases are fully automated. When a PullRequest is merged into next, AppVeyor builds an installer and releases it with a version according to the current wildcard specification. That specification is usually <maj>.<min>.<patch>.<build>, where <maj>.<min>.<patch> are equal to the latest green release.

Rubberduck uses semantic versioning even though we're not a library. For prereleases AppVeyor fills in the build part with the current build number across the project.

This means build numbers in our semantic versions are monotonously increasing and non-contiguous. Or in a slightly less mathy way of speaking: The larger the build number, the later it released and there may be holes between releases with their build numbers.

Green releases

For green releases, it's a little more complicated.

A green release always comes with an adjustment to the current version specification. In most cases this means incrementing the patch version, sometimes it means increasing the minor version (and resetting the patch version).

AppVeyor will generate a release draft for us with a prefilled message. To make best use of git features, we use annotated tags when tagging green releases (helps with git describe and allows us to add more information to a tag). The release process for a green release is the following:

0. Get a release date and put in the work :)

1. Open a PullRequest from next to master

2. Write a release note draft

3. Prepare a "Version Bump" PullRequest (into next) that adjusts the version specification (e.g. #4873, see "Version Bump")

4. Do the actual releasing:

   • Merge the release PullRequest
   • Create an annotated tag at the new master named v<maj>.<min>.<patch>
   • Edit the release draft to point to the newly created tag and to contain the release notes and publish it

5. Merge master into next (preferrably using a fast-forward merge)

6. Merge the "Version Bump" PR

This way the first prerelease with the new green release's base version is the same binary as the green release itself. Additionally a fast-forward merge results in a commit graph that looks something like the following:

o  [next, Prerelease-v...] Merge Pull Request <>
o  [master, Prerelease-v..., v...] Merge Pull Request into master
|\
| o  [Prerelease-v...] Merge Pull Request <>
| o  [Prerelease-v...] Merge Pull Request <>
|/
o  [v..., Prerelease-v...] Merge Pull Request into master
|\
| o ...
.
.

This kind of commit history vastly simplifies conflict resolution and "ancestry determination". Note that each of the "Merge Pull Request <>" commits skips over the commits that it introduced into next. Ideally these subsections of the commit graph look very similar to those outlined above.

For green releases we additionally write basic release notes.
Data for these release notes is gathered as described in this entry