Unity Release Process

This document describe the release process for Unity and Unity-2d, and all the depending components. It relies on our automated packaging and merging infra we put in place during the Precise cycle.

We pushed an automated building infrastructure with public test reports to have commits automatically tested, pushed to the trunk of development branch as well as available packages in a ppa.

Procedure

We decide of a "freeze week" when the initial goal is to release on Thursday at the latest.

Step 1: Freeze

On Monday, we freeze the trunk for all unity and related projects. This means, no more new code can enter unity at this point (as well for all the related components like unity-2d, nux, dee, libunity, bamf, unity lenses…). Only selected branches can now get in, and those are picked only if they contribute to getting closer to this release quality.

Freezing is done on the server side by touching a /tmp/releasing.block file. The UNBLOCK keyword can be used in a merge request description to make a branch entering any trunk on a freeze period.

Step 2: First testing from distro

We ensure then on Tuesday that people can safely install the new release candidate from the unity-team ppa. This contains of what will soon be the next version of unity and is automatically generated from all the trunks.

If any ABI break impacting main components not part of unity (like nautilus, empathy, update-manager…), we rebuild them in the ppa as well so that people getting the ppa don't end up with a non working desktop. Note that we only deal with the main ones, not every reverse dependencies at this stage at it's a time consuming operation.

Step 3: ensuring the distro test cases are up to date

The desktop experience team qualified the release using their manual tests and running automated ones again like autopilot ones.

The distro side check that the tests cases in checkbox-unity are still up to date with the new unity release candidate, adapt them if needed. Once done, they upload checkbox-unity tagging the version for the new release candidate version.

If we spot serious regressions, we directly head to dx to get the issues fix (and the merge request will contain the UNBLOCK tag) and after automated validation, the new fix will ends up in the previous ppa. This is done until the quality is good enough for crowdsourcing the tests.

Step 4: community testing

When installing from the ppa, and every time there is a new release candidate period, the checkbox-unity package is installed and prompt for getting help on testing. A new launcher icon is added as well. Note that the autoprompting period automatically ends after the release candidate reaches the main archives and appears only once per release candidate period for the user.

An official call is made as well on planet.ubuntu.com for community testing.

Step 5: wrapping up results

We want at least a full day here. We collect then results from the unity result collector and run it locally. Then, the process is manual: the tool show only the tests that failed and the number of them, or the tests that passed, but getting a comment. To know the number of people testing, we just need to look at the unity/version test (which is mandatory).

From those results, we can decide if we release unity or not, what additional regressions should be fixed (and new package built, and so on). We can go back to step 3 if the release shows the quality isn't good enough and we need full testing again.

For regressions/issues spotted that are not important enough to block the release, we file them as bug, and put an additional "unity-distro-priority" bug task so that it shown on this page: http://people.canonical.com/~platform/design/upstream.html in the "Distro Priorities" section.

Step 6: getting full bug list

This can be started before the previous elements are gathered. This is about getting all bugs that are fixed by the release having an upstream "unity" bug task set to "fix committed" and milestoned to the current release milestone.

Note that there is no need for setting all bugs that are not fixed in this milestone to the next one, as the unify script will do that in a latter step. They just need to not be "fix committed"

Step 7: actual upstream release

Then, it's time for release. We bump the configure.ac or cmake file with the new version. We commit that and tag the commit with the release version. Finally, we directly push that to launchpad.

We then issue tarballs for every projects trunks we need to upload. This is the traditional "make dist" step and signing the tarball, uploading it to launchpad and attaching to a milestone.

Step 8: packaging

The packaging was automatically generated in the ppa, it doesn't get the same quality than the packaging we can do by hand. So this step is about getting the packages updating (most of the time with the "merge-upstream" workflow) from upstream trunk and upstream tarball. We bump build-dependencies correctly, make the necessary packaging tweaks, check that everything is building fine, install them and some additional (but lighter) testing. We as well update the changelog for every projects with the list of bugs that are closed.

To generate the changelog, we run the unify script. bin/unify -R unity will gather all the fixed bug for one particular release, cutted down in a changelog format (80 caracters large, formatted), sorted per components.

Then, unify will close all upstream bug reports that are in "fix committed" state for the particular milestone and set all still opened bugs to the next available milestone. Not that there is also a -R unity-2d parameter for unity-2d.

Step 9: upload

Finally, we upload all the previous packages to launchpad, rebuilding all reverse dependencies for external components if there is an ABI break. (in that case and considering the number of components, it's important to start the upload in the morning to not break the CD image build).

To conclude, it's high time to announce the new release and thanks all the contributor by a blog post.