Release Cycle

Status

• Created: 2005-04-23 by MattZimmerman
  

• Priority: MediumPriority
  

• People: MattZimmermanLead, ColinWatsonSecond
  

• Contributors: MattZimmerman, ColinWatson, AdiAttar, JordiMallach
  

• Interested: JorgeBernal, JeffWaugh
  

• Status: DraftSpec, BreezyGoal, UduBof, DistroSpecification, MattZimmermanQueue
  

• Packages:
  

• Depends:
  

• UduSessions: 1
  

Introduction

Review our experiences with the existing release strategy and discuss possible improvements.

Rationale

Our current release strategy has worked pretty well, but it has encountered some teething problems as new developers, documenters, translators, and so on have joined our community. We need to review and update it.

Scope and Use Cases

Implementation Plan

At the moment, our release cycle looks like this:

• T-18 weeks: seed freeze
• T-13 weeks: upstream version freeze
• T-12 weeks: remaining merges complete
• T-8 weeks: feature freeze
• T-5 weeks: preview freeze
• T-4 weeks: preview release
• T-1 week: final freeze, release candidate
• T: release

The Hoary release cycle exposed a few problems with this arrangement. Notably, there is no string freeze, and thus translators had problems keeping up to date; there is no point where we freeze the user interface that needs to be documented; we do not adequately notify relevant people of freeze exceptions; and the time allocated between feature freeze and the preview release is a little too short to allow new features to settle down.

We propose the following changes to the release cycle:

• Remove seed freeze The usefulness of the seed freeze has proven to be limited. In practice, we have made necessary seed changes quite late in the cycle, and we always review the supportability of new packages in main regardless of when they are introduced. Instead of an artificial and false seed freeze, we will instead simply take other freeze conditions (upstream version freeze, feature freeze, etc.) into account when making seed changes. This codifies existing practice.
• Move UVF and feature freeze one week earlier The gap between feature freeze and the preview release is too short, and a number of new features did not receive adequate testing before the Hoary preview. To alleviate the rush, we will move feature freeze one week earlier. Upstream version freeze will move one week earlier to correspond with this: in practice, we have been content to allow reasonable exceptions to the upstream version freeze, so this should not be a problem.
• Institute string freezes After consultation with some Ubuntu translators, we will institute a string freeze, to coincide with preview freeze (T-5 weeks). At this point, no translatable strings outside documentation may change without prior confirmation, and any exceptions must be communicated to translators. This should allow translators time to finish their work before the final release. Since documentation needs to be updated to cope with code changes, we need to allow it a little more time to come up to date, but it nevertheless needs to be translated. We will institute a documentation string freeze, to coincide with the preview release (T-4 weeks). At this point, no translatable strings in the documentation may change without prior confirmation, and any exceptions must be communicated to translators.

  Translations for the installer and other packages not covered by language packs (e.g. openoffice.org) must be complete by T-2 weeks. Translations for packages covered by language packs must be complete by T-1 week if they are to be included in the final release; failing that, they will be included in post-release updates.

• Institute UI freeze Documenters need to have a stable user interface against which to write end-user documentation. To allow for this, we will institute a user interface freeze, one week before preview freeze (T-6 weeks), which by the GNOME 2.10 schedule would have been one week after the GNOME UI freeze. At this point, changes affecting the system's user interface require prior confirmation, and any exceptions must be communicated to translators. Assuming that documentation has been kept reasonably up to date with major changes throughout the cycle, this allows two weeks for further updates before the documentation string freeze.
• Kernel freeze Changes to the kernel require significant user testing. Testing by the development team often fails to uncover problems that only occur on unusual hardware. At the same time, we often need to make late changes to the kernel in order to fix security vulnerabilities. We will stop making changes to the kernel other than security fixes at T-2 weeks. Any non-security changes after this date will require prior confirmation.
• Communication Developers, documenters, translators, and other interested parties all find it useful to know about significant events in the release cycle in advance, and to be notified of exceptions so that they can take account of them in their areas of responsibility.

  We will notify relevant mailing lists of significant events in the release cycle one week in advance. If possible (MartinPitt is investigating), we will notify translators automatically of string changes from the feature freeze onwards. We will create a mailing list (name TBD - ubuntu-release?) where freeze exceptions are requested and approved or rejected; this formalises the current IRC-based process, and allows those people not on #ubuntu-devel to find out about exceptions and why they were made.

• Release timing It is desirable to avoid uploads on the day of release even for feature goals. Therefore, since GNOME releases take place on Wednesdays, we will plan our releases to take place on Thursdays, and allow this to slip to Friday if absolutely necessary.

Following these changes, the release cycle looks like this:

• T-14 weeks: upstream version freeze
• T-13 weeks: remaining merges complete
• T-9 weeks: feature freeze
• T-6 weeks: UI freeze
• T-5 weeks: preview freeze, string freeze
• T-4 weeks: preview release, doc string freeze
• T-2 weeks: artwork, installer, non-langpack translations, kernel non-security
• T-1 week: langpack translations, release candidate
• T: release

Data Preservation and Migration

Packages Affected

User Interface Requirements

Outstanding Issues

Should release announcements be written well in advance so that they can be translated? (It can spoil the surprise if we write them too early.)

UDU BOF Agenda

• Everybody loves newer software
  • The backports mess
  • What are the valid use cases, and can we accomodate them within Ubuntu?
    • Making new packages available to users of stable releases
    • Making new versions of existing packages available to users of stable releases (at what granularity?)
• Phases of freeze
• Release rollup / checklist items
  • Artwork
  • Translations
    • String freeze
    • Installer translations
    • Non-langpack translations
    • Langpack translations
  • Documentation
    • Screenshots
    • Translations?
    • Behaviour changes
  • Kernel
  • Uploads of packages which go on the CD
  • Uploads to main
  • Uploads to universe

UDU Pre-Work