Changes between Version 18 and Version 19 of RFC/4_ReleaseProcedure


Ignore:
Timestamp:
May 13, 2022, 7:00:43 AM (5 months ago)
Author:
veroandreo
Comment:

minor grammar fixes - we should revise trac references in step 2

Legend:

Unmodified
Added
Removed
Modified
  • RFC/4_ReleaseProcedure

    v18 v19  
    1515
    1616 * 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  * A release period should be a time of concerted action during which all developers give priority to the release in place of other developments.
     17 * A release period should be a time of concerted action during which all developers give priority to the release instead of other developments.
    1818 * All developers respect a call for commit freeze during a release process.
    1919 * It is sometimes better to ship a release with a known bug than with unknown consequences of an untested bug fix.
    20 
    2120
    2221== General Procedure ==
    2322
    2423Step 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 ([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 and decides whether there is sufficient support for this proposal.
     24   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 the Release manager, if exists) then collects reactions and decides whether there is sufficient support for this proposal.
    2625
    2726Step 2 (day X) - Soft freeze of release branch:
    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, the first announcement is sent by the Release manager to the developers mailing list about the upcoming release along with a trac planning page (section). Immediate effect of this announcement is a soft freeze, meaning that commits should be limited to non-invasive backports from the development branch/trunk. The announcement should also include an approximate time table for the release, including the start 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.
     27   * If support is lacking, a list of outstanding issues (managed via https://github.com/OSGeo/grass/issues) that need to be solved before a soft freeze should be sent to the developers mailing list.
     28   * If sufficient support is present, the first announcement is sent by the Release manager to the developers mailing list about the upcoming release along with a trac planning page (section). The immediate effect of this announcement is a soft freeze, meaning that commits should be limited to non-invasive backports from the development branch/trunk. The announcement should also include an approximate time table for the release, including the start 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.
    3029
    3130Step 3 (X+30 days) - Hard freeze & RC1:
     
    3837   RC2 is released as almost final.
    3938
    40 Step 6 - Bug squashing: & Release preparation:
     39Step 6 - Bug squashing & Release preparation:
    4140   A final, concerted bug squashing effort by all developers of no more than one week. During that same time the release announcement is drafted. If an important bug is discovered for which a fix needs some more testing, an RC3 can exceptionally be published, with another week of testing before final release.
    4241