Multipass release process

Multipass
, ,
1

NB: This document is mostly interesting to Multipass developers, not its consumers :slight_smile:

The topic

The Multipass team has decided to adhere to the Semantic Versioning schema for versioning software. It’s a growing standard ensuring common language between projects on what a version string describes. This document is meant to summarize the decisions made and the process to adhere to it.

The format

In short, we’ll be releasing Multipass with the version string in the following formats (in increasing order):

0.6.0-dev.123+g123abc
0.6.0-rc.234+g23abcd
0.6.0

In Semantic Versioning terms, dev.123 are “pre-release identifiers” and g123abc — “build metadata”.

On top of that:

  • +win and +mac suffixes will be used to mark builds for Windows and macOS respectively
  • the dev and rc identifiers denote a development build and release candidates
  • the number following the period is the number of commits since the last release
  • and the hexadecimal string following +g is the Git commit abbreviation.

The process

To avoid multiple sources of truth, Git will remain the authoritative place for sourcing version information. Signed, annotated tags will describe final releases, while plain -dev and -rc suffixed tags will denote start of development for a version or a branch working towards a release.

Before release

  1. if applicable, commit and tag a -dev commit for the next major/minor version

    git checkout main
git commit --allow-empty --message "Begin 0.7.0 development"
git tag v0.7.0-dev
git push --follow-tags origin main

  2. tag the -rc commit and push the release/<MAJOR>.<MINOR> branch

    # if preparing a major/minor release
git checkout --branch release/0.6 v0.7.0-dev^
git tag v0.6.0-rc

# or, if preparing a patch release
git checkout --branch release/0.6 v0.6.0
git tag v0.6.1-rc

git push --follow-tags --set-upstream origin release/0.6

    and create a Pull Request for it

During release

  1. work on main as usual
  2. cherry-pick merges onto the release branch
    git cherry-pick --mainline 1 <merge commit>
  3. if necessary, commit directly to the release branch

On release

  1. tag the release commit with a GPG signature and annotation
    git tag --sign v0.6.1
git push --follow-tags public release/0.6
  2. merge the release Pull Request via bors
  3. build and publish the release to the stable channel in the Snap Store and on the GitHub releases page as appropriate
  4. publish Release Notes on discourse

Feedback

If you have anything to say about this approach and process, please let us know below!

1 Like