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:
+macsuffixes will be used to mark builds for Windows and macOS respectively
rcidentifiers 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
+gis 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
-devcommit 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
-rccommit 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 main 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
stablechannel 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!