Channels for snaps are composed by three parts joined together by slashes: track/risk/branch.
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 stable, candidate, beta, or edge, and 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.
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 less risks than the tolerance 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.
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.
The branch part is optional and missing by default, and allows 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 to users via the command interface. 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.
