Release Management

Release Management

We use semantic versioning for our releases. This is represented by the dotted version numbers: #major.#minor.#maintenance.

Repository Setup

The git repository is laid out like this:

• branches:
  • master - All development happens here. Pull-requests should be made against master
  • x.y - Maintenance branches for tracking bugfixes
  • your_feature_branch - topic branches for features that are under development
• tags:
  • releases/x.y.z - Tags representing each release.

Release Process

1. Create a tag named releases/x.y.z where x.y.z is the version number being released.
2. GitHub Actions will trigger based upon the tag name and create the release.
3. Edit the generated release document to include the changelogs, release notes, etc.
4. If this is a ".0" release, create a maintenance branch. (e.g. If we're releasing 1.0.0 or 1.2.0, create a branch named 1.0 or 1.2, respectively.

Maintenance Releases

Maintenance releases require some extra steps because we need to ensure that changes we ship with the maintenance release are also included with the main development branch. With Git, there are two ways to do it that are roughly equivalent - merging or cherry-picking.

Merging method

1. PRs with bugfixes are created against the maintenance branch and merged.
2. A new tag releases/x.y.z is created against the maintenance branch, x.y, triggering GitHub Actions to create the release.
3. Edit the release document to include the changelogs, release notes, etc.
4. Merge the maintenance branch into master.

Cherry-pick method

1. PRs with bugfixes are created against master, as normal.
2. Commits merged into master are then cherry-picked into the maintenance branch.
3. A new tag releases/x.y.z is created against the maintenance branch, x.y, triggering GitHub Actions to create the release.
4. Edit the release document to include the changelogs, release notes, etc.