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 candidate (Owners)
After 48 hours, if no bug reports filed indicating regressions from the previous version, push to stable
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.
For you Owners, though, it would be easiest if you just made the commit and immediately pushed to edge so people wanting the latest release (regardless of potential snap stability issues) can get it and people can get testing so we can push it to stable.
Fair, whatās your definition of āa good shakeā? If we require an āit works OKā message from someone (or more than one person) before pushing out of edge people could be waiting indefinitely for a releaseā¦ But maybe that is the way forward, people wanting a release faster can install the edge snap and test it. But it would just be good to have a set process for releases rather than the current uncertainty over what we do to get new releases out. Should there be a minimum period for testing? How many a-okās do we need before promoting the snap? What do we accept as an a-ok, how comprehensive a test?
Ideally we should be writing automated tests for the snaps, if they pass the tests we should be able to bump them up the channels pretty fast (but we need to determine how fast for all of these cases). Indeed, this is what snappy currently expects upstreams to do given that automatic refreshes are obligatory. Weāre not an upstream, but if we wanted to speed up releases I guess weād have to find or make some automated tests to run, which would be time-consuming (I donāt have the time) and requires expertise in that area. So thatās the ideal case. In practice weāll just need to ask real people to test snaps and lay out how weāre going to promote snaps on the basis of that.
OK, so I guess, from now on, we need to post a call for testing when a new stable release hits edge?
Thanks for raising this @Ads20000 and sorry for the delay to reply.
I broadly agree with your process and I agree with @evan that for applications which have pushed out a point release of their application, where the snap builds with no changes (other than version number) a āgood shakeā is usually good enough. Examples where this isnāt the case is where discord broke from 0.0.1 to 0.0.2 when some dependency was unfulfilled. But thatās okay because the app failed to build and land in the store anyway. So once we realised that we needed some work to get the right dependencies and fix it. In that process we had to do some testing anyway, which was way more than āa good shakeā.
Iād like us to be better at a few things:
Getting these things upstreamed where the upstream hasnāt already told us theyāre not interested.
Noticing when upstreams push out new versions, and cranking a build. I am told build.snapcraft.io will grow some better machinery around this to make it less manual - perhaps @evan can speak to that.
Responding to PRs from our community on snapcrafters repos promptly. We havenāt been good at that, and we should fix that. We did a lot of gardening of the issues last week, and weāll make sure we keep on top of that, ongoing.
Yes, @cprov and team are implementing builds triggered once per day if any of the dependencies (source: entries in your snapcraft.yaml) have changed. This has been running in dry run mode on production for a while and is just waiting on some frontend work.