Release Process

This page describes OLPC's software release process.

Goals

The goals of the release process process are to:

1. Ensure high quality releases which meet the needs of users in a timely fashion.
2. Maximize the participation, productivity and enthusiasm of the open source community.
3. Create a predictable process which helps users and developers plan for the future.

The process

Each release is planned in advance, and this process results in a slightly different development/release methodology for each release. However, certain guidelines and well-established principles are stuck to:

• The release planning documentation is made public from the start.
• Release development is divided into individual stages, separated by milestones (discussed below)
• Releases are coordinated according to a schedule of milestones, which is decided early on, and included in the release plan.
  • This is important so that our customers know when to expect the final release, when they should get involved with development and testing, and to allow them to plan their upgrade/rollout.
  • This is also a well-established practice in our neighbouring open source communities
• The release schedule is honored strictly. That is, the milestone dates are adhered to, even if some sacrifices (such as exclusion of planned features which didn't arrive in time) are made. Some flexibility can be allowed for, but these should be exceptional cases only.

The development process is divided into distinct stages, with milestones to mark the progression from each one to another.

1. Planning
2. Development
3. Bug fixes only
4. Regression fixes only
5. Release

Major and minor releases

Major releases include large platform changes (such as updating to the latest versions of Fedora & Linux) and addition of new features.

Minor releases (a.k.a. point releases) are limited to the fixing of bugs which are affecting deployments, and occasionally include translation and locale updates (requested by deployments).

This was previously adhered to quite strictly, but the recent minor releases in the 10.1 series have seriously blurred the lines between major and minor releases. This degrade of practice started when OLPC's development resources were downsized, meaning that there were no resources in sight to allow for a future major release, resulting in the relaxing of criteria on what could go into the minor release. However, now that OLPC's software team has grown a bit again, it is my hope that this previous practice can be restored, so I've documented it that way. Time will tell... -DanielDrake 17:22, 9 February 2011 (UTC)

Features

New major releases will include a set of new features, pioneered and developed by OLPC staff and community members. A feature is defined as a significant change or enhancement to the current version of XO software that may or may not include new packages.

Features are usually considered to meet one or more of the following objectives:

1. Highly user visible changes
2. Improvements or changes that require non-trivial cross-package integration
3. Noteworthy enough to call out in the release notes
4. Exciting new capabilities we can trumpet.

Some examples might include:

• New educational tools that will be used by children
• New features from upstream that we are making available on the XO for the first time
• Improvements to tools and infrastructure used by activity developers

Additionally, features can enter releases through upstream projects. For example, a new feature added to GNOME will automatically enter an OLPC release once a release is made including that specific version. Some of these features may have direct impact on OLPC and are good candidates to be discussed in the release notes.

Release Names

Recall that Releases consist of a family of builds derived from a reference OS, along with "polish" like documentation, signatures, and installable images. It is assumed that end users including students will use a Release.

The release names are of the form "Y.H.NN"

• Y = target calendar year
  
• H = major release number representing first release or second release of the calendar year
  
• NN represents the Minor Release, starting with .0 at the availability of the first Major Release and going up by 1 for each publicly available minor release after that.

A Major Release and all its derivative Minor Releases can be referred to with a variable (or wildcard) in the third digit (e.g. 8.2.x refers to 8.2.0, 8.2.1 and 8.2.3).

Example Names

• 8.1.1 First Minor Release rebuild based on the first Major Release in CY08
  
• 8.2.0 Second Major Release in CY08
  

Major and Minor Release will have code names before they are released.

Build Names

Recall that Releases consist of a family of builds derived from a reference OS, along with "polish" like documentation, signatures, and installable images. It is assumed that end users including students will use a Release.

The build family consists of a reference OS named:
official-nnn
which lives on http://download.laptop.org/xo-1/os/official/. The word "official" means that it is a final Major or Minor Release build (link to doc, etc.). The "nnn" is an integer uniquely identifying the source code. An example is official-703.

Derivative builds may be created locally by anyone. However, cryptographic signatures are required to enable "cheap" mass installation of the derivatives. No signatures are required if you are willing to use OLPC-supported USB customization technology or if you request developer keys for all your machines.

Derivative builds are named as follows:
variant-nnn-n
The "variant" field is typically a short string identifying a deployment or language group such as "peru" or "en". When the build name does not start with "official" it means that either:

• the reference operating system was customized to produce a derivative build, in which case the name will be as above, or
• a fork has taken place.

For example,

peru-703-6 is the customized build created for Peru based on the source code identified by 703.

and

en-708-1 is the English language customization of release candidate build 708. This is not an official Release unless and until official-708 is released and it is documented on the release page.

Types of Builds

Each build consists of a core OS.

One way of classifying a build is to identify its readiness to be a Release.

There are four types of builds in that classification:

1. Released images - (a.k.a. "stable") with release notes and ECO. This is a signed image which does not need a developer key to install on an XO. (e.g. official-767; the OS component of the 8.2.0 Release)
2. Release candidates - (a.k.a. "testing") release candidates which are in change control and may become official releases if it passes the test cycle. (e.g. candidate-800; tentatively the OS component of the 8.2.1 Release )
3. Development images - (a.k.a. "unstable") - the latest image with the latest code but it is also likely to contain significant bugs. (e.g. joyride-2072)
4. Experimental images - images which are not expected to work and which are used for creating major new functionality; typically a part of "topic branches". (e.g. faster-2072)

More details on available builds and how to get them are here.

See also: build system

For a developer wanting to contribute new code we recommend the following steps:

1. Decide whether you want to hack on activities, releases, bugs, or experimental features.
2. Choose the corresponding build type: released images, candidates, development images, or your own topic branch.
3. Send an e-mail to devel@lists.laptop.org and/or sugar@lists.laptop.org explaining your work and gathering feedback.
4. Implement a basic first pass which compiles and shows the main idea. Post a link to its source to the same lists, preferably in a patch-like format.
5. Revise as needed based on feedback.
6. If possible, get the changes included in an upstream repository or, as appropriate, ask the list for details on how to package it locally for the XO. One useful link on including packages in Fedora is here

Release candidates are the builds that may replace the current 'stable' designation. Release candidates are created during the execution of software engineering change orders. See details of ECO creation steps in the Release Process page and An Example ECO for 8.1.1

Note: each successful build generates products that can be installed on some system. For example, release builds contain disk images suitable for flashing to NAND, for consumption by OLPC update, for inspection on other systems, and for simulation in QEMU. Traditionally, important builds are announced on devel@lists.laptop.org.

Steps to Create a New Major Release

Step 1 - New Major Release is named and tracking wiki page is created

Step 2 - Release objectives and lead customer identified. Target features listed and target date down to the month is chosen.
The module maintainer, with his peers and the community comes up with a set of target features for the release. Product Management participates in the discussion and informs it based of customers feedback. Product Management and the relevant module maintainers are responsible to build consensus. The module maintainers are responsible to ensure that the code going in git repositories is consistent with that consensus.

Step 3 - Schedule is posted per below

See also

• Release Process Home/Historical - historical plans for parts of the release process