NB: This document is mostly interesting to Multipass developers, not its consumers
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.
In short, we’ll be releasing Multipass with the version string in the following formats (in increasing order):
In Semantic Versioning terms,
dev.123 are “pre-release identifiers” and
g123abc — “build metadata”.
On top of that:
+mac suffixes will be used to mark builds for Windows and macOS respectively
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.
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
-rc suffixed tags will denote start of development for a version or a branch working towards a release.
if applicable, commit and tag a
-dev commit for the next major/minor version
git checkout master
git commit --allow-empty --message "Begin 0.7.0 development"
git tag v0.7.0-dev
git push --follow-tags origin master
-rc commit and push the
# 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
- work on master as usual
- cherry-pick merges onto the
git cherry-pick --mainline 1 <merge commit>
- if necessary, commit directly to the
- tag the release commit with a GPG signature and annotation
git tag --sign v0.6.1
git push --follow-tags public release/0.6
- merge the release Pull Request via
- build and publish the release to the
beta channel in the Snap Store and on the GitHub releases page as appropriate
- publish Release Notes on discourse
If you have anything to say about this approach and process, please let us know below!