Ubuntu Wiki

The Release Process

Each release cycle follows the same general pattern, with the following major phases. UbuntuDevelopers are expected to track this process closely, and ensure that their work is aligned with that of others. TimeBasedReleases mean that we need to be well coordinated in our efforts to produce an on-time release.

Beginning a new Release

At the beginning of each cycle, the Ubuntu infrastructure is prepared for a new branch of development. The package build system is set up, the toolchain is organized, seeds are branched, and many other pieces are made ready before development can properly begin. Once these preparations are made, the new branch is officially announced and opened for package uploads.

Planning

The features to be targeted for each release cycle are organised using specifications. Some of these come from strategic priorities for the distribution as a whole, some are proposed by individual developers, and some are drawn from the IdeaPool or the list of existing specifications (long). The proposed features are discussed at the DeveloperSummit at the beginning of each release cycle, and soon after, the TechnicalBoard and its advisors review proposed features and select a set of development projects which fit together well into the overall plan for the release.

The planned feature list for the current release cycle (Ubuntu 9.10, Karmic) can be found at http://blueprints.launchpad.net/ubuntu/karmic/+specs, and the schedule at KarmicReleaseSchedule.

Merging with Upstream

The first phase of the release cycle is characterized by bringing new releases of upstream components into Ubuntu, either directly or via Debian. We merge from Debian because it's the single most effective way to keep up to date with upstream code (Debian maintainers package new upstream releases on a frequent basis, often faster than we are able to do so), and because Debian and Ubuntu are similar in many ways so their bug-fixes are often bug-fixes for us too. We do it every release cycle rather than taking the occasional cycle off because if we didn't it would be significantly harder ever to come back into sync. Anything that we don't modify - strictly, anything whose version number does not contain the substring "ubuntu", and which isn't in the manually-maintained blacklist - is "synced" from Debian semi-automatically: the source package is copied verbatim and rebuilt on our builds. Anything that we've modified either needs to be merged by a developer, or needs a developer to request that the package be synced overriding the Ubuntu changes in the event that Debian took all our changes or they no longer apply for some other reason. Managing to get a package back into sync is usually a good thing, as it saves us from having to put maintenance effort into that package.

For more information on the practicalities of this process, see the Syncing and Merging section.

This phase can be said to end when all packages have been brought up to date at least once, and the result has been sufficiently stabilized to produce the first milestone, with installable CD images. This must be no later than the DebianImportFreeze for the release cycle.

Feature Development

During this phase, the focus is on development projects which have been planned for the release. These projects often begin while merging is still underway, and accelerate the pace of their development once the package archive is reasonably consistent and usable.

Stabilization (Freeze)

During the course of development, we gradually exercise greater caution in making changes to Ubuntu, in order to ensure that we reach a stable state in time for the final release date. The typical order and length of the various freezes can be seen on the current ReleaseSchedule and the ReleaseScheduleTemplate. During freezes, uploads are sometimes held in a queue for manual approval. A mirror of this queue is available to ease coordination during these periods.

Exceptions to the current freeze criteria can be requested using the FreezeExceptionProcess.

• Open Development - unrestricted general development activity, new packages and versions automatically imported from Debian

• DebianImportFreeze - unrestricted general development activity, new packages/versions from Debian only on request, all packages merged with Debian

• FeatureFreeze - no new features, packages, or APIs/ABIs, only bug fixes

• UserInterfaceFreeze - no user interface changes (stabilize for documentation and screenshots)

• BetaFreeze - uploads by release manager approval only (stabilize for beta release validation)

• DocumentationStringFreeze - no string changes in master documentation any more (stabilize for doc translations)

• KernelFreeze - no new kernels (stabilize for final hardware compatibility checks, deadline for kernel regression fixes)

• ReleaseCandidate - uploads by release manager approval only (stabilize for final release validation)

Milestones

During the development phase of a release we regularly create and test CD images, which mark milestones in development and are used for more widespread testing of the current development release status:

• The first Alpha milestone after about two months, when the initial flood of new upstream versions, merges with Debian, and first set of new features landed.
• Three Alpha milestones in intervals of three weeks until feature freeze and upstream version freeze, to get early testing of new features.
• Two more Alpha milestones in intervals of two weeks for stabilizing the new features and fixing the worst bugs.
• The Beta milestone three to four weeks before the final release.

The Alphas are verified to check that the installation succeeds and at least give a working system. They often require some tweaks and workarounds afterwards to get it actually usable (like some applications not starting by default, or getting a lot of crash reports). Thus these are aimed at developers and interested technically savvy users from the community. This is particularly important to exercise the installer and getting early feedback about new features.

The Beta release is feature complete and free of major bugs (like the installer failing, installed applications do not work at all, or the desktop crashing consistently). They get extensive testing on a lot of hardware. It is recommended for a larger (but still technically inclined) audience. From then on, upgrades to the final release are supported and guaranteed to succeed.

All Alphas announced on the ubuntu-devel-announce mailing list. Due to the more widespread focus of the Beta, its announcement goes to ubuntu-announce. The announcements contain general information about the focus and download addresses.

For each Alpha and Beta there is also a more in-depth article on the Testing page of the Ubuntu website, which describes new features, caveats, and other important information.

The process of creating a milestone and the communications involved from the Release Manager's point of view are explained in detail in MilestoneProcess. Developers need to be aware that the archive gets frozen a few days before a Milestone is scheduled, in order to stabilize the archive, avoid jeopardizing installability, and giving control to the release manager what goes into the Alpha milestone CDs.

Finalization

As the final release approaches, our focus narrows to fixing "showstopper" bugs and performing very thorough validation of the installation images. Every image is tested to ensure that the installation methods work as advertised. Low-impact bugs and other issues are deprioritized in order to focus developers on this effort.

This phase is important, as severe bugs which affect the experience of booting or installing the CD must be fixed prior to the final release. Ordinary bugs which affect the installed system, in contrast, can be fixed with StableReleaseUpdates.

Stable Releases

Released versions of Ubuntu are intended to be stable. This means that users should be able to rely on their behaviour remaining the same, and therefore, updates are only released under special circumstances. These criteria, and the procedure for preparing such an update, are described in StableReleaseUpdates and SecurityTeam/UpdateProcedures.

Go back to UbuntuDevelopment.
CategoryProcess
CategoryUbuntuDevelopment