Changes between Version 1 and Version 2 of ReleasePractices/PostBetaMerges


Ignore:
Timestamp:
Oct 27, 2008, 1:10:02 PM (14 years ago)
Author:
Beman Dawes
Comment:

Suggestions from Joaquín M López Muñoz, John Maddock

Legend:

Unmodified
Added
Removed
Modified

  • ReleasePractices/PostBetaMerges

    v1 v2  
    33== Introduction ==
    44
    5 These branches/release merge policies cover the period between when a beta ships and the final release. They are intended to ensure quality, yet avoid requiring developers get permission for totally routine commits.
     5These branches/release merge policies cover the period between when a beta ships and the final release. They are intended to ensure quality, yet avoid requiring developers get permission for certain routine commits.
    66
    77== Policy ==
    … …  
    1111 *  '''Showstoppers.''' Criteria: Bugs or other problems so serious that the release is seriously compromised if not fixed. Procedure: After discussion on the developers list, release managers will specify how the problem is to be attacked, and what effect it will have on schedule.
    1212
    13  * '''Documentation and other minor fixes not affecting code.''' Criteria: Changes not requiring regression testing and unlikely to impact other libraries. Procedure: Merges to branches/release are OK, after fix applied to trunk, and do not require a release manager's permission.
     13 * '''Code changes and fixes.''' Procedure: Ask release managers for permission. Rationale: While we do want to fix problems, particularly regressions, stability is a major concern at this point in the release cycle.
    1414
    15  * '''Minor code fixes.''' Criteria: Changes believed to have limited risk and that have already been made to trunk and are stable on trunk regression testing. Procedure: Merges to branches/release after fix stable on trunk tests do not require a release manager's permission.
    16 
    17  * '''Questionable code fixes.''' Criteria: Any code changes not meeting the "Minor code fix" criteria, such as a change with a lot of possible ripple effect on other libraries. Procedure: Ask release managers for permission.
     15 * '''Documentation fixes and other minor changes not affecting code.''' Criteria: Changes not requiring regression testing and unlikely to impact other libraries. Procedure: Merges to branches/release are OK, after fix applied to trunk, and do not require a release manager's permission. '''Important:''' If applicable, check the daily snapshot to verify the change did not break the documentation build.
    1816
    1917 * '''Tools changes and fixes.''' Code changes to bjam, Boost.Build, Boost.Test, the doc build process, and other tools are discouraged late in release cycles in general and between beta and release in particular. Ask release managers for permission if you really think the change is warranted for this release.
    … …  
    2321== Acknowledgments ==
    2422
     23Joaquín M López Muñoz, John Maddock helped with the development of this policy.
     24
    2525----
    2626Copyright Beman Dawes 2008