Warning /!\ This document is deprecated and replaced by UbuntuCoreReleaseProcess . Please do any modification in the new document.

This document describes the different steps that 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 involved in the pipeline.

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) + image PPA (https://launchpad.net/~snappy-dev/+archive/ubuntu/image)

The edge PPA will receive a new snapd deb daily, it will be used for builds of os and kernel snap with automated submission to the edge channel in the store.

The image PPA will contain experimental changes and test code , it is the developer playground where cross-package changes land and plumbing development happens.

Gate: automated executions in pull requests: static analysis, unit and integration tests.

Post-publication checks: Once the CI system detects the new os snap in the edge channel, integration, autopkgtests and upgrade + rollback will be triggered against it.

The PPAs 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.

Beta: xenial archive + xenial-proposed

Package changes from the PPA get regularly submitted into xenial-proposed and weekly snap builds make an automatic submission to the beta channel in the store. The platforms available are currently amd64 and x86, but we hope to get armhf in the cloud or LXC, bbb and dragonboard testbeds.

Gate: post-publication checks from the previous stage.

Post-publication checks: When the new snaps are detected by the CI system by the integration tests that can run in all the platforms we have available in the lab, plus update and rollback tests

This is the channel we will recommend people to use if they want to help testing the new release. People aiming at regular -proposed testing (for regular SRU verification etc) will use the beta snaps from the store for this.

(Release) Candidate: xenial-archive + xenial-security/-updates

On demand builds (with fall-back to bi-weekly when we do a release. Automatic submission to the candidate channel in the store. 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.

Gate: post-publication checks from the previous stage.

This build has all the verified SRUs and is our regular release candidate, the builds from this channel get additional manual testing under a proper release plan and get moved to the stable channel once verified.


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.

QATeam/OSSnapPromotion (last edited 2017-02-28 08:29:43 by jibel)