Changes between Version 7 and Version 12 of RFC/4_ReleaseProcedure
- Timestamp:
- (multiple changes)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RFC/4_ReleaseProcedure
v7 v12 10 10 == Summary == 11 11 12 In order to render the release process more fluid, to avoid very long RC periods and to lessen the potential for conflict between developers during release preparations, this RFC proposes a procedure that should be followed for each release.12 In order to render the release process more fluid, to avoid very long RC periods and to lessen the potential for conflict between developers during release preparations, this RFC defines a procedure that should be followed for each release. 13 13 14 14 == General philosophy == 15 15 16 * The release process should be short. I.e. the time between the first RC and the final release should be a matter of weeks not many months.16 * The release process should be ''short''. I.e. the time between the first RC and the final release should be a matter of weeks not many months. 17 17 * A release period should be a time of concerted action during which all developers give priority to the release in place of other developments. 18 18 * All developers respect a call for commit freeze during a release process. … … 23 23 24 24 Step 1 - Proposal of release: 25 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.25 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 ([http://lists.osgeo.org/mailman/listinfo/grass-dev grass-dev AT lists.osgeo.org]). The Project manager (or if exists Release manager) then collects reactions to decide whether there is sufficient support for this proposal. 26 26 27 27 Step 2 (day X) - Soft freeze: 28 28 * If support is lacking, a list of outstanding issues (managed via http://trac.osgeo.org/grass/) that need to be solved before a soft freeze should be sent to the developers mailing list. 29 * If sufficient support is present, a first announcement is sent about the upcoming release. This announcement has as immediate effect a soft freeze meaning that commits should be limited to non-invasive backports from the development branch/trunk. 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. Any backports during the soft freeze should be announced on the developers mailing list with 24 hours advance to allow possible discussion.29 * If sufficient support is present, a first announcement is sent the developers mailing list about the upcoming release. This announcement has as immediate effect a soft freeze meaning that commits should be limited to non-invasive backports from the development branch/trunk. 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. Any backports during the soft freeze should be announced on the developers mailing list with 24 hours advance to allow possible discussion. 30 30 31 31 Step 3 (X+30 days) - Hard freeze & RC1: … … 33 33 34 34 Step 4 - Bug squashing: 35 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.]35 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.]~~ 36 36 37 37 Step 5 (X+44 days) - RC2:
