To @popey @Wimpress @evan in particular:
We need some sort of proper release process for snaps in the snapcraft repo. What should we do, consistently, when an update is released upstream for a snap that we have?
Example release process:
- Atom 1.21.0 is released
- Change version numbers in the
snapcraft.yaml and make a PR (non-Owners) or commit (Owners)
- Push to
beta ASAP (Owners)
- If the snap launches successfully (non-Owners/Owners to confirm), push to
- After 48 hours, if no bug reports filed indicating regressions from the previous version, push to
The above is just an example. Because we may not much use the software that we’re packaging, the above is very minimal on testing (assuming that there should be no new regressions in new releases, we’re just updating the version numbers in the snap, it should just work) to get a snap out ASAP. Perhaps it should be heavier on testing. But we need a proper process of some sort.
Also, we need the
contact field for each snap filled so that people know where to go to report issues for each snap (I’ve filed Issues against each snap in the repo asking for that to be done).
(I should probably also use RSS feeds so I can spot updates faster, apparently you can just add
.atom to the end of a GitHub Releases URL to get an RSS feed for the releases!)
Would be nice to do candidate/beta/master releases as well, particularly for GIMP, perhaps we could continue the discussion from @evan’s comment here, or we could just accept what he says and just target
stable! Doing more than
stable is kinda dependent on a few GitHub Issues being fixed elsewhere anyway.