Snapd release process

Snapd has two types of releases, major versions and minor versions. Major version releases correspond to a version number such as 2.53, while minor versions correspond to a version number such as 2.53.1. The chief difference between them is usually what motivated the release - we are always preparing for another major version in a few weeks time, but sometimes we need smaller sets of changes such as targeted interfaces or bugfixes sooner than that, so we do minor versions sooner rather than waiting for the major version.

Typically, large refactorings are left out of minor releases, such that the difference between a major release and the next subsequent minor release (i.e. 2.53 -> 2.53.1) is as small and targeted as possible. This is not always possible because sometimes bugs or features are complex, but that is the overarching goal.

The typical release process flow goes something like this:

  1. All the code for the next version of snapd is merged to the master branch in git.

  2. For a major release, we will then create a new branch from master, named release/<VERSION>, where VERSION is always the major version number. This branch is also where we will tag minor releases after this major release.

  3. After the branch is created, we sometimes still need to land some more things before we tag, so after we are as sure as we can be that everything for the next release is on the release/ branch, we will tag it and sign the git tag with one of our GPG keys that can be found at launchpad.net for one of the maintainers of snapd who has permission to create the release.

  4. From this tag, we then will build multiple artifacts for snapd for different places, this includes:

  5. Debian packages for the minimal necessary Ubuntu distros in the snappy-dev image PPA - this is because we build the core snap from this PPA as well as the initrd for UC20 from this PPA, currently this list of distros is just xenial and focal.

  6. The snapd snap

  7. The core snap

  8. Source tarballs with the vendored Go code, without the vendored Go code and with only the vendored Go code - these are mostly used by other distributions to build their packages of snapd.

  9. Other traditional linux package formats such as debs for debian upstream, rpms for fedora and derivatives, etc.

  10. After those things are built, we will release the core snap and the snapd snap built from this tag directly to the beta channel. We do not release this revision to the edge channel, and we do not release revisions from the edge channel to beta or higher channels. In fact there are different jobs for the different channels such that a revision of the snap that goes into the edge channel will never go into the beta/candidate/stable channels and vice versa.

  11. After being released to the beta channel, some automated tests run and we will put out a call for testing with some teams internal to Canonical about the new version of snapd.

  12. If all of that testing comes back good, we leave the snapd and core snaps in the beta channel for at least 2 weeks.

  13. After waiting in beta for approximately 2 weeks, we then move to candidate and if all teams have reported back positively about the release, then using progressive releases we release the snaps to stable (sometimes we need to wait a bit longer for feedback and so it may wait in candidate a while longer). We almost always will wait to do the final release to stable on a Monday or Tuesday. See https://snapcraft.io/docs/progressive-releases for details, but there are many many many users of the core and snapd snaps, so we release it progressively both to catch potential issues before they are pushed out to everyone and also to optimize bandwidth usage.

  14. At this point, we start the SRU process to release an updated version of the debian package of snapd to Ubuntu releases in the main archive, including doing ESM builds/uploads as necessary.

The version number of snapd released to stable always will map 1:1 with the version number of a released revision of the snapd or core snap. For example, for the git tag 2.51.1, there is exactly one revision that will be published with this version number. This helps to simplify debugging, where the output of the snap version command, will allow us to find exactly the revision of the snapd or core snaps that correspond to that version that was released.

The version number of snapd released to the edge channel of the core and snapd snaps however does not follow this pattern. The version number of the snapd snap released to edge includes the git commit that the snap was built from, so that you can track what specific git commit the edge revision was built from. It is not recommended to follow the edge channel for production use cases, as things may break in unstable ways, but the stable channel will always maintain backwards compatibility to the extent that we are technically able to while still fixing bugs or security issues. The version number of the core snap released to the edge channel is slightly more complicated, as the git commit included there actually is the commit of the snapd-vendor project in launchpad, which includes the snapd source code and the vendored Go dependencies.

Sometimes, when providing fixes for specific things where we are either not ready to do a release (for example we just did a release and need to wait for that to be released before we can release another one), we will build branches of snapd with specific fixes for specific situations. In this situation, only affected parties will be told about the branch and the branch will usually be closed after the fix has been confirmed and landed into master and then subsequently shows up in a release to the stable channel.

We do not have specific “code freezes” like some projects when it comes to landing changes, usually we will tag PR’s on GitHub that need to wait for the next major release as “Blocked” and set the appropriate milestone so that it doesn’t get accidentally merged before the next major release branch is created. After the release branch is created, we usually try to tag the release as soon as possible, but since sometimes new bugs come in or features need to be backported from landing to master to be included in the release branch, we may cherry-pick commits from master onto the release branch before tagging the release on the release branch. However after a release is tagged, we will never re-tag it, so if an issue is found with say release 2.54 which prevents us from releasing with that, we will start all over again with a 2.54.1 release instead and 2.54 will never reach the stable channel.

If you are curious about what new features are included in the next major release of snapd, you can look at the roadmap page here: https://snapcraft.io/docs/snapd-roadmap. The timelines for future releases on that page should not be relied on for anything, they are simply estimates. The dates given for already released versions of snapd should be exact and refer to the major version, not to any associated minor versions (since minor releases generally do not include new features, only bug fixes or very small and targeted features).

The best way to determine when the next version of snapd will be released is to reach out to us on IRC or the forum and we will provide you with the best estimate we can at the time.

3 Likes