Changes between Version 9 and Version 10 of ReleaseSchedule


Ignore:
Timestamp:
Feb 11, 2009, 1:41:33 PM (14 years ago)
Author:
Beman Dawes
Comment:

1.39.0 dates set

Legend:

Unmodified
Added
Removed
Modified

  • ReleaseSchedule

    v9 v10  
    55'''Note well: Changes must always be committed to trunk and be stable on trunk regression testing before being merged to branches/release.'''
    66
    7  * '''December 20, 2008:''' branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries.
    8  * '''January 3, 2009:''' branches/release closed for major code changes. Still open for serious problem fixes and docs changes.
    9  * '''January 10, 2009:''' branches/release closed for all library changes except when specific permission given by release manager(s).
    10  * '''January 17, 2009:''' Beta release target date. Further betas and/or release candidates as feedback dictates.
    11  * '''January 31, 2009:''' Release ship date.
     7 * '''March 13, 2009:''' branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries.
     8 * '''March 20, 2009:''' Release managers start QA checks.
     9 * '''April 3, 2009:''' branches/release closed for major code changes. Still open for serious problem fixes and docs changes.
     10 * '''April 10, 2009:''' branches/release closed for all library changes except when specific permission given by release manager(s).
     11 * '''April 17, 2009:''' Beta release target date. Further betas and/or release candidates as feedback dictates.
     12 * '''May 1, 2009:''' Release ship date.
    1213
    1314== Future Releases ==
    … …  
    2425 * One week after prior release ships: branches/release opens for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. '''New libraries may be added with permission of a release manager.'''
    2526 * Seven weeks before release: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries.
    26  * Five weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install.
     27 * Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install.
    2728 * Four weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes.
    2829 * Three weeks before release: branches/release closed for all library changes except when specific permission given by release manager(s).
    … …  
    3738 4 weeks: 0 votes, 6 weeks: 0 votes, 8 weeks: 10 votes, 12 weeks: 25 votes, 16 weeks or longer: 6 votes
    3839
    39 The last day of the month is chosen rather than the first day, because January 1st comes after a holiday period in which it is hard to get anything done.
     40The first day of the second month of the quarter is chosen because the first day of the first month in the January quarter comes after a holiday period in which it is hard to get anything done.
    4041
    4142The schedule for release milestones is based on practical issues like the length of time it takes regression tests to cycle, and is adjusted as experience dictates.