Ubuntu Wiki

This document describes the different steps a new OS snap needs to take before reaching the stable channel. It includes the different gates and the validation criteria for its transition between the different channels.

The main goal is to get a saner core snap and be able to release it often and in a predictable date.

Edge: xenial archive + edge PPA (https://launchpad.net/~snappy-dev/+archive/ubuntu/edge)

The edge PPA will receive a new deb daily after master (from https://github.com/snapcore/snapd) has passed the integration (run over an allsnaps amd64 image) and autopkgtest (classic amd64 and i386). The PPA will be used for the automatically imported snapd packages, for test uploads, feature development across multiple packages etc, this is the "go wild" area. people using the snaps from the edge channel in the store need to be prepared for potential breakage.

This channel is also gated by the automated executions in pull requests: static analysis, unit and integration tests.

Beta:

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 testbeds. 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.

Stable:

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.

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.