In the snap world channels define which releases from a particular snap the system will be observing and attempting to install new revisions of.
For example, this command installs a new revision from latest/stable, or stable short:
$ sudo snap install vlc
While this one will pick up the latest beta snap, if there is one available, or otherwise something more stable than that:
$ sudo snap install --channel=beta vlc
Again, beta and latest/beta refer to the same channel.
Once a snap is installed the system will continued observing the channel used during installation, and during refresh attempts it will pick up new revisions that are made available to that channel, directly or indirectly (see details below).
After installation the channel for a particular snap may be changed during a refresh:
$ sudo snap refresh --channel=candidate vlc
And it may also be changed via the switch command with no immediate interaction with the store:
$ sudo snap switch --channel=offline
snap info command will display the channel being used by the given snap under the
The channel name structured as three parts separated by slashes:
The track defines the series of versions that may be obtained for snaps in the given channel. Different projects use different conventions for its tracks according to its internal practices. For example, certain projects use tracks named after the minor version of the project (3.2) implying only micro releases of that specific version will be found under that track (3.2.5). Other projects hold tracks for its LTS (long-term support) releases, so version numbers may change even across majors (3.2 → 4.1). The default track is latest and is implied when the field is missing.
At this time and to encourage consistency and sanity in the ecosystem tracks must be explicitly requested via the #store forum category. Also, “guardrail” regular expressions are applied to the versions being released in specific channels to ensure that mistakes are not made and reasonable user expectations are not broken. For example, only 3.2.* versions are accepted into a 3.2 track.
The risk part must necessarily be one of:
It conveys the stability level of snaps in the given channel. These terms may not match exactly the internal conventions used by the project (some will say alpha instead of edge) but they are close enough to the most accepted conventions, and allow users to express their risk interest across all snaps in a consistent way.
The stable and candidate channels are said to be of stable grade, while beta and edge are said to be of devel grade, and that small distinction is in place to help prevent process mistakes that could result in unintended versions hitting production users and causing major harm.
Closing a channel is a convenient way for the snap publisher to tell the world that there’s nothing available with that exact specification right now, but closing a channel does not change the choice of systems following it. Instead, when the channel of a specific risk level is closed the snap store will internally fallback to the next channel of the same track that offers a more conservative choice than the risk specified.
For example, if a client is following a beta channel but that channel is closed, the store will offer the current snap in the candidate channel if one is available, or the one from stable otherwise. In that scenario the client continues following the beta channel, though, and once the channel is reopened the client will refresh into the snap released there.
If it sounds a bit confusing, the important thing to remember is that this logic means the behavior is correct and what you would expect: if you ask for a beta, you get a beta, unless something even more recent and more stable than that beta is made available, in which case there’s no reason to stay behind.
The branch part is optional and missing by default. Its purpose is to allow the creation of short-lived sequences of snaps for experimentation or other temporary purposes. Branch names must convey the reason for their existence, and although accessible to anyone that would have access to other channels of the given snap, these names are not exposed in the snap information by default.
Branches also have an enforced expiration time at which point the branch will be closed. Similar to the behavior described above when considering risk levels, once a branch is closed the store will offer clients the snap in the most appropriate channel. For example, a stable/fix-bug-42 channel will fallback to stable once the fix-bug-42 branch is closed.