All snaps have a default track. Without the snap developer specifying otherwise, the default track is called latest. Similarly, when no track is specified, a snap will implicitly install from the latest track. The track can also be specified explicitly:
Developers can optionally choose whether to supplement the default latest track with additional tracks. The developer is also free to designate one of these as the default track to be installed when no further preference is given.
Developers must currently make a request for tracks to be added to their snap via the #store-requests forum category. Releases are verified and checked to ensure that reasonable user expectations are being met. For example, only 3.2.* versions are accepted into a 3.2 track.
Candidate releases are considered almost ready for going into stable, but need some additional real world experimentation before they move forward. Software reaching this stage will typically have passed all available QA and review processes, since users following it expect a high stability level. Should almost never break.
Beta is the first level towards the stabilisation of what was before a fast moving stream of changes. Specific projects may have slightly different terminology for such releases (alpha, beta, etc) but all of these are welcome on this risk level. These releases will almost certainly have passed some sort of review and QA, but may still have unfinished parts. Breaking changes are still relatively common here.
Edge releases often include a moving stream of changes without QA or review promises and are typically built automatically by a CI process from an arbitrary source code snapshot. Often the CI will only publish after some sort of automatic QA passed, and code reviews remain a good practice, but these are project specific. Assume edge releases may break often.
This option will not automatically refresh the snap to force the installationof a new snap. To switch channels and update the snap with a single command, add the --channel option to the refresh command:
A branch is an optional, fine-grained subdivision of a channel for a published snap that allows for the creation of short-lived sequences of snaps that can be pushed on demand by snap developers to help with fixes or temporary experimentation.
After 30 days with no further updates, a branch will be closed automatically. The replacement snap will then be chosen as it would be with closed channels (see below). For example, beta/fix-for-bug123 will fall back to beta after the fix-for-bug123 branch is closed.
For example, when a specific risk-level channel is closed, the snap store will select a snap from a more stable risk-level of the same track. If the original channel is re-opened, snaps will once again be selected from the original channel.
This approach is commonly used for beta testing. If a snap is following a beta channel that is then closed, the store will offer the snap from the candidate channel. If the candidate channel is not available, the snap from the stable channel will be selected. If the beta channel re-opens, the snap will once again be selected from that channel.
795a8134c1