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.
