Release Policies and Procedures

1. Release countdown:

• 1.1. Starts when a release manager finalizes an internal list of tasks for the upcoming release together with code freeze date on the release page. Each feature on release page is described by an owner, pointer to a design doc/page (on github), status notes (what has been done and what remains to do), days remaining, motivation of the feature, and expected done date.

• 1.2. The release manager updates this list regularly and resets the dates as needed -- if the overall release date changes an email is sent to nimbusteam with the new estimated date.

• 1.3. A release will also include an overall statement why we want it.

2. Release design:

• 2.1 Tasks get scheduled or linked to design documents and rough time estimates are given for each feature. Based on those estimates the release manager estimates the code freeze and RC1 date.

3. Release implementation:

• 3.1. Tasks get put on the github page within a week of expected code freeze and RC1 dates get finalized and an email gets sent to -dev soliciting contributions. A rough estimate of release time also gets put on github page.

• 3.2. Two weeks before code freeze we give people heads-up of the code freeze and RC1 dates.

• 3.3. The deadline for contributions is code freeze -- but we encourage contributions early

• 3.4. Feature implementation includes documentation and feature testing.

4. Code freeze: Things to do: more testing in a real place (not your laptop), tarballs get produced.

5. RC1/RC2/final cycle is pretty standard

• 5.1. One problem in the past was feature additions. Very small ones that people really need seem OK (like a FG showstopper for example, that a day's work could fix). But in 2.5 there were more significant add-ons after RC1. "Technically" RC1->RC2 should not add any feature at all.