Release Process/Stabilization

General process

At a point defined by the release plan, release development switches from a model of open development to a model of slower, controlled development focused on stabilization.

Once this stage is reached, no more features should be accepted. All contributions should be made in the purpose of fixing something.

The stabilization stage is usually split into 2 parts: bug fixing, regression fixing. The timing of each part is defined in the release plan.

Bug fixing stage

During this stage, the only changes accepted are changes that solve issues. These issues should be described in tickets on trac. Contributions that add features, perform code cleanups, or do anything that isn't a clear solution to a ticket is pushed off until the next release.

Fedora packages are continued to be pulled in, as Fedora policies state that package updates within a particular Fedora release should be bug-fixes, not major updates.

Translations continue to be accepted.

The process of contributing packages to the build system, Fedora packages, RPM dropboxes, and kernel stays the same as it was for Release Process/Development (but the release manager will now start vetting these changes in more detail). The process of contributing new Sugar activities is described below.

At least one month should be spent in this stage. The target is to have a release-quality build at the end of it.

Freezing Sugar activities

Unlike Fedora, our upstream for Sugar activities (http://activities.sugarlabs.org) has little concept of QA or introducing features only at certain points during well-defined cycles. We often find that new versions of activities add obvious bugs. Therefore we use the point of entering the stabilization stages to freeze our selection of Sugar activities and only selectively bring in changes which we have verified to solve problems without adding new ones.

The build system configuration must be updated at this point.

The initial freeze

When entering the stabilization stages, the release manager should create G1G1 (for XO-1.5) and G1G1Lite (for XO-1) activity wiki pages for the particular release, using the major/minor numbers of the release as the final component of the page name, e.g. Activities/G1G1/11.2 and Activities/G1G1Lite/11.2. Refer to previous activity pages for examples.

These pages (and the pages they include) must be constructed and edited with care. Some activities may already have pages that you can include, but you will likely need to bump up the version of the activity that they refer to. When doing that, you should take care that you are not modifying the versions presented for earlier major releases. For example, if "Record (latest)" is included in G1G1/8.2 and you now include it in G1G1/11.2 and modify it to point at the latest version which is not compatible with the earlier release (if you haven't tested, assume that it is incompatible) then you are going to cause problems for the userbase. The correct approach in this case is to copy "Record (latest)" to "Record (8.2)", modify the 8.2 activities page to refer to "Record (8.2)", then proceed to update "Record (latest)" and include it in the 11.2 pages.

Activity updates

After freezing activities, bugs will probably be identified and fixed in later versions. When this happens, the fixed activity version must already be on http://activities.sugarlabs.org. The responsible developer should put the appropriate ticket in state "add to build" along with a link to the latest version on activities.sugarlabs.org.

The release manager will then update the wiki before the next build is made, moving the ticket into "test in build".

Other code contributions

With the exception of Activities above, to get code included in the builds, follow the process from the development stage.

Regression fixing stage

At the end of the bug fixing stage, the release team should be happy with the release and should be happy to push it out the door. This final stage represents final testing, and hopefully only includes a very small amount of changes. All development builds are now signed, which has historically resulted in a significantly heightened level of testing from the community.

The only changes that are accepted in this stage are regression fixes -- fixes to bugs that exist in this particular release which did not exist in earlier OLPC releases. Bug fixes for "old" bugs (ones that we've always had, or ones that are related to new features) aren't accepted, but are pushed off til the next release (which could be a point release swiftly following the release now being finalized), and are documented clearly in the release notes.

Occasionally, fixes are additionally taken for important non-regression bugs when the fix is trivial (e.g. one line of code), well understood and well reviewed.

When requesting changes to be included in a build, please be mindful of the aim to greatly reduce the rate of change at this point - we aim for few changes at this stage. This allows for maximum reliability of the testing that occurs and allows us to release software that we fully understand. It is possible to argue that any specific change is a regression fix (perhaps by generalising) yet the release manager should be quite strict in the changes that get applied. Your cooperation is appreciated!

At least one month should be spent in this stage. Development builds are continually produced, but they are now known as "release candidates".

When entering this stage, the release page of the release to set the status property to "in testing".

Contributing changes

1. Regression fixes to sugar activities should be fixed in new versions uploaded to http://activities.sugarlabs.org
2. Regression fixes to Fedora packages should be fixed and submitted to fedora-updates-testing
3. Regression fixes to dropbox packages should be fixed with new packages submitted to the dropbox
4. Regression fixes in the build system and kernel should be approved by the release manager then pushed to the appropriate repos

In all cases, every change must be represented according to a ticket on trac, fully describing the regression. After performing the above steps, mark the ticket as "add to release" with a comment explaining where to find the new version. If accepted, the release manager will then take the final steps so that it gets included in the next build.

Freezing packages

At the start of this stage, we stop accepting updates from Fedora and freeze the package selection, for complete change control and consistency. This is all described in the Frozen repositories documentation.

The build system configuration should be updated at the same time so that these repositories are used instead of Fedora's.

Builds

All builds should be signed at this point, which means access to the signing keys is required. Chris Ball is the key-holder.

Builds should now be placed on on download.laptop.org as candidates (e.g. http://download.laptop.org/xo-1/os/candidate/), rather than being uploaded to build.laptop.org as they were before.

The release notes should be drafted at this point, including download and installation instructions (pointing to the latest candidate build). The release page (e.g. 11.3.0) should be modified, removing download/install instructions, and instead pointing to the release notes as a source of this information.

A file named .readme.html should be created on the top-level release directory on build.laptop.org (e.g. http://build.laptop.org/11.3.0) explaining that the builds have moved. The contents of this file are shown as a footer to the directory listings. Example contents:

11.3.0 has now progressed into release candidate phase;
<b>the latest 11.3.0 builds can no longer be found here.</b>
<br><br>

Please refer to the
<a href="http://wiki.laptop.org/go/Release_notes/11.3.0">release notes</a>
for download instructions of the latest candidate builds, which are hosted
on <a href="http://download.laptop.org/">download.laptop.org</a>.

Write release notes

Each new release should be accompanied by detailed release notes explaining the improvements and significant bug fixes present in the release, alongside installation/upgrade instructions, download links, and any known issues. We generally start writing final release notes at this point in the cycle, and publish them for peer review (marked as a draft with the {{draft}} wiki-tag).

The release notes should be published under the Release notes page, e.g. Release notes/8.2.0.