release cadence and channels for the ubuntu-core snap

Leo Arias leo.arias at
Wed Mar 2 14:46:35 UTC 2016

Hash: SHA256


Today we discussed about using the four channels that the store
offers. We want a saner ubuntu-core snap and be able to release it
often and in a predictable date.


We will build an ubuntu-core snap for every change in the snappy
master branch and release it to the edge channel. This channel is
gated by the automated executions in pull requests: static analysis,
unit and integration tests.
- - Merge the pull requests with master before running the tests to
prevent conflicts.
- - Add a test job that builds the debian package.
- - Talk with the store, spi and launchpad teams to share as many tools
as possible.


Every night we will run all the automated tests we have using the edge
channel. If everything is green, we will have an automatic promotion
to beta. This channel is gated by the integration tests that can run
in all the platforms we have available in the lab, plus update and
rollback tests. The platforms available are currently amd64 and x86,
but we hope to get armhf in the cloud or LXC, bbb and dragonboard
This is the channel we will recommend people to use if they want to
help testing the new release.

Release Candidate:

Every two weeks, we will promote from beta to release candidate. We
will use this channel to do a lot of exploratory testing. And as
almost every RC version will be the same as a stable version, we will
verify the updates and rollbacks. We will test RC in the boards that
we don't have available in the lab, and we will manually run the few
tests that can't be automated.
We will use the first two or three releases to find new gates and
process changes that will let us release every week.


Once we are happy with the exploratory testing on RC, we will promote
to Stable. After the promotion, we will trigger the automated tests
again and verify updates and rollbacks.
TODO: discuss with ogra the hook into the image generation process.

A note on securiy fixes:
When there's a new CVE, we want to release the fix as soon as possible
to stable. This will be easier if we can cherry pick only the fix
instead of generating the snap normally, because we want to avoid
bringing additional non-security-related package updates.

- - discuss about the planning of scenarios or stories before starting a
new cycle.
- - discuss about the commits and changelog that goes into stable.
- - find a way to include in the changelog the package updates that are
new to the release.

During the following weeks we will be arranging the gates, and
figuring out the build and upload process. And after the first
releases we'll be making adjustments for sure, so please send us your
suggestions if you have any.

pura vida
Version: GnuPG v2


More information about the snappy-devel mailing list