Changes between Version 2 and Version 3 of RFC/4_ReleaseProcedure

Timestamp:

Jun 11, 2014, 3:15:25 AM (10 years ago)

Author:

martinl

Comment:

--

RFC/4_ReleaseProcedure

@@ -22 +22 @@
 == General Procedure ==
 
-Step 1 - Proposal of release: When a developer feels that it is time for a new release, she or he should propose the launch of a new release process on the developers mailing list. The Project manager (or if exists Release manager) then collects reactions to decide whether there is sufficient support for this proposal.
+Step 1:
+   Proposal of release: When a developer feels that it is time for a new release, she or he should propose the launch of a new release process on the developers mailing list. The Project manager (or if exists Release manager) then collects reactions to decide whether there is sufficient support for this proposal.
 
-Step 2 (day X)- Soft freeze: If sufficient support is present, a first announcement is sent about the upcoming release. If support is lacking, a list of outstanding issues that need to be solved before a soft freeze should be sent to the developers mailing list. This announcement has as immediate effect a soft freeze meaning that commits should be limited to non-invasive backports from the development branch. Any such backport should be announced on the developers mailing list with 24 hours advance to allow possible discussion. The announcement mail also contains an approximate time table for the release, including begin of hard freeze, RC1, RC2, final release. Sufficient time should be left between the soft freeze and the hard freeze.
+Step 2 (day X)- Soft freeze:
+   If sufficient support is present, a first announcement is sent about the upcoming release. If support is lacking, a list of outstanding issues that need to be solved before a soft freeze should be sent to the developers mailing list. This announcement has as immediate effect a soft freeze meaning that commits should be limited to non-invasive backports from the development branch. Any such backport should be announced on the developers mailing list with 24 hours advance to allow possible discussion. The announcement mail also contains an approximate time table for the release, including begin of hard freeze, RC1, RC2, final release. Sufficient time should be left between the soft freeze and the hard freeze.
 
-Step 3 (X+30 days) - Hard freeze & RC1: Once any necessary backports are done, a hard freeze is announced and RC1 is released based on the frozen code. 
+Step 3 (X+30 days) - Hard freeze & RC1:
+   Once any necessary backports are done, a hard freeze is announced and RC1 is released based on the frozen code. 
 
-Step 4 - Bug squashing: All developers concentrate on fixing the remaining bugs during a defined period of no more than 2 weeks. Any commits from that point on can only be well-tested, non-invasive bug fixes. [tbd: a specific svn branch with access limited to a release team of 2-3 developers can be created. Any fix has to be sent to the release team for approval and commit.]
+Step 4 - Bug squashing:
+   All developers concentrate on fixing the remaining bugs during a defined period of no more than 2 weeks. Any commits from that point on can only be well-tested, non-invasive bug fixes. [tbd: a specific svn branch with access limited to a release team of 2-3 developers can be created. Any fix has to be sent to the release team for approval and commit.]
 
-Step 5 (X+44 days) - RC2: RC2 is released as almost final.
+Step 5 (X+44 days) - RC2:
+   RC2 is released as almost final.
 
-Step 6 - Bug squashing: & Release preparation: A final, concerted bug squashing effort by all developers of no more than one week. During that same time the release announcement is drafted.
+Step 6 - Bug squashing: & Release preparation:
+   A final, concerted bug squashing effort by all developers of no more than one week. During that same time the release announcement is drafted.
 
 Step 7 (X+50 days) - Final release