By Daniel Manrique, Engineering Manager at Canonical, Online Services
Ever since snaps were introduced, a crucial part of their feature set has been the ability to release a snap on a particular “channel” indicating how stable or production-ready it is. The well-known channel names stable, candidate, beta and edge indicate a snap’s stability, according to the developer, and users are then empowered to choose the level of risk they are prepared to accept when installing a snap.
From a developer’s point of view, it makes sense to release new changes on edge, which will presumably have a small number of users willing to accept some instability in exchange for bleeding-edge features (but also, tacitly, a disposition to report problems), and as any rough edges are taken care of, release the updated snap to beta, candidate and finally to stable once it’s deemed adequate for anyone to use.
The typical means for discovering snaps (the “snap find” command) reveals only snaps in the stable channel. Snaps can be installed from other channels by simply using a command-line parameter (
snap install --channel=candidate, for example), but those releases will not appear in search results. Developers are encouraged to publicize releases to the riskier channels via blog posts, tweets or direct communications with users and only make their snap discoverable by any user when it’s considered stable enough.
These four channel names are always available for users to subscribe to, but a developer doesn’t necessarily have to release explicitly to every channel, thanks to a behavior known as “following”. If there is no revision currently released in a channel, it is in a “closed” state and the store will offer whichever revision of the snap is in the next most stable channel.
So if a developer does:
$ snapcraft release my-snap 37 stable Track Arch Channel Version Revision latest amd64 stable 37 37 candidate ^ ^ beta ^ ^ edge ^ ^
Then a user subscribing to the candidate channel via:
snap install my-snap --channel=candidate
Will still get revision 37 of my-snap.
As the developer releases subsequent revisions to stable, any users who installed from candidate will be updated to those revisions.
Channels are more useful, clearly, when the developer releases something different to each of them. So for instance, when a new candidate version (revision 50) is ready, the developer can do:
$ snapcraft release my-snap 50 candidate Track Arch Channel Version Revision latest amd64 stable 37 37 candidate 50 50 beta ^ ^ edge ^ ^ The ‘candidate’ channel is now open.
When a snap is explicitly released into a channel, the channel ceases to follow the previous one and is now “open”. The developer can then release a newer revision into stable:
$ snapcraft release my-snap 51 stable Track Arch Channel Version Revision latest amd64 stable 51 51 candidate 50 50 beta ^ ^ edge ^ ^
At this point, people installing or refreshing from candidate will still get the explicitly-released revision 50.
Does this mean that once a snap is released into a channel, the developer must manually keep the channel up to date? No! The “following” behavior can be restored by “closing” the channel, which means it will fall back to offering the same revision as the immediately-more-stable channel.
$ snapcraft close my-snap candidate Track Arch Channel Version Revision latest amd64 stable 51 51 candidate ^ ^ beta ^ ^ edge ^ ^ The candidate channel is now closed.
In our example, people who had installed from candidate will now refresh to revision 51, and start getting subsequent updates released to stable.
In addition to the stability progression, the well-known channel names have one special behavior to help ensure that software isn’t released to a channel it’s not suitable for: Snaps with grade: devel or confinement: devmode can only be released to edge and beta channels (here are some pages with more information about grade and confinement options).
These four “channels” have always been a well-known component of the snap experience. But now, a revelation: did you know those names are actually called “risks” and are only one component of an actual channel name? Full channel names have three parts: track, risk and branch, and they give developers powerful mechanisms with which to control the delivery of software to users. A full channel name looks like this, with slashes delimiting the components:
Only the risk component (what we had been calling “channel” until now) is mandatory (and is the only one restricted to a set of options, namely the four well-known stable, candidate, beta and edge risks). All snaps have an implicit latest track (which is why things worked when we didn’t specify a track), and the “branch” component is optional. So when you say stable, it actually means latest/stable; beta is latest/beta and so on.
In part two, we’ll look in detail at tracks and branches. Tracks can be used to have multiple “stable” versions, so users can choose to either follow the latest “stable” or use an older major version, usually for compatibility reasons. Branches are custom “temporary” channels to which a snap can be released and are useful for releasing “hot fixes” and code changes that apply to limited audiences.
Learn how the Ubuntu desktop operating system powers millions of PCs and laptops around the world.
Last week, much of the IoT industry descended on Santa Clara, California, for the annual IoT World trade show. One of the exhibitors present were Rigado who Canonical partnered with earlier this year to deploy Ubuntu Core on their…
In case you missed it, here are some of the snaps we featured during April 2018. Here you’ll find snaps to enhance your productivity, tools for creatives, IDEs for developers and games for the weekend. You can stay up to date with…
Last Friday (11 May 2018) we learned that a snap was mining cryptocurrency in the background while the application was running. The practical implication of that is the overuse of local resources on a user’s system, well beyond what a…