I’m wondering how other snapcraft projects handle rc/pre/alpha/beta versions? Do you release them to the beta
or edge
channels? Do you have a particular git workflow with different branches that map to the various release channels? I’m curious how others handle beta-testing of new software versions (not necessarily beta testing changes to the snapcraft.yaml
file itself) via snapcraft?
For that, usually candidate and edge is used
Typically I use candidate
for landing updates to snaps that are used out in the field, and I use edge
for snaps that I am actively developing and have not released yet.
For our Mir based snaps:
Channel | use |
---|---|
edge |
Snap main + Mir main branch |
beta |
Snap main + Mir “release”/“release candidate” |
candidate |
Promoted from beta following testing (Mir “release” only) |
stable |
Promote from candidate following “call for testing” |
Ultimately I basically only ever use stable.
Even when outright asking with blog posts to a technical audience on a snap with tens of thousands of users over its lifetime, there’d never actually been any feedback on them, and keeping up with e.g Nightly builds on the edge channel ended up not being worth the effort to myself personally.
Though in theory when I do use them, it’s along the grade
property which is stable
and devel
, candidate holds preview of stable releases (effectively release candidates that could in theory go straight into stable with no code change), whereas beta
is tagged pre-releases and edge
is nightlies. These by my definitions would never go into stable so in some snaps I do actually set the grade to devel
automatically to ensure the store itself will enforce that.
Ultimately I guess a lot of how you approach this comes down to whether Snap itself is seen as part of your offering or only a technical detail of one extra way to get things to your users. Since I only repackage upstream stuff, the stable releases are already 99% tested and the 1% on myself is only sandboxing stuff, that only infrequently changes.