Changes between Version 13 and Version 16 of RFC/4_ReleaseProcedure


Ignore:
Timestamp:
(multiple changes)
Author:
(multiple changes)
Comment:
(multiple changes)

Legend:

Unmodified
Added
Removed
Modified

  • RFC/4_ReleaseProcedure

    v13 v16  
    66Contact: [http://lists.osgeo.org/mailman/listinfo/grass-psc grass-psc AT lists.osgeo.org]
    77
    8 Status: Early draft (11 June 2014)
     8Status: Late draft (7 Jan 2015)
    99
    1010== Summary ==
    1111
    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.
     12In order to render the release process more fluid, to avoid very long release candidate (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.
    1313
    1414== General philosophy ==
    … …  
    2525   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 the Release manager) then collects reactions to decide whether there is sufficient support for this proposal.
    2626
    27 Step 2 (day X) - Soft freeze:
     27Step 2 (day X) - Soft freeze of release branch:
    2828   * 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 to 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.
     29   * If sufficient support is present, a first announcement is sent by the Release manager to the developers mailing list about the upcoming release along with a trac planning page (section). 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 and the link to the trac page. 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.
    3030
    3131Step 3 (X+30 days) - Hard freeze & RC1:
    32    Once any necessary backports are done, a hard freeze is announced and RC1 is released based on the frozen code.
     32   Once any necessary backports are done, a hard freeze is announced by the Release manager and RC1 is released based on the frozen code (release branch).
    3333
    3434Step 4 - Bug squashing:
    … …  
    4343Step 7 (X+50 days) - Final release published.
    4444
    45