Changes between Version 14 and Version 15 of ReleaseSchedule

Timestamp:

May 23, 2012, 3:25:13 PM (10 years ago)

Author:

Beman Dawes

Comment:

Stretch out beta period, schedule 2nd quarter release a week earlier because of BoostCon.

ReleaseSchedule

@@ -1 +1 @@
 = Release Schedule =
 
-Releases are scheduled for the first Monday of the second month of each quarter:
+== Release Dates ==
 
  * First Monday in February
- * First Monday in May
+ * Last Monday in April (i.e. a week early to allow extra time before for BoostCon/C++Now!)
  * First Monday in August
  * First Monday in November
 
-Release milestones
+== Release milestones ==
 
 '''Note well: Changes must always be committed to trunk and be stable on trunk regression testing before being merged to branches/release.'''
+ * Upon release shipment: branches/release open 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 only with permission of a release manager.'''
+ * 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.
+ * Seven weeks before release: Release managers begin QA checks on snapshot doc builds, inspect status, getting started guide, and install.
+ * Six weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes.
+ * Five weeks before release: branches/release closed for all changes, except by permission of a release manager.
+ * Five days before beta release: branches/release closed. Release managers begin building release candidates.  
+ * Four weeks before release: Beta release.
+ * Upon Beta release: branches/release open for bug fixes and documentation updates. Other changes by permission of a release manager.
+ * One week before release: branches/release closed for all changes, except by permission of a release manager.
+ * Five days before release: branches/release closed. Release managers begin building release candidates.  
 
- * 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.'''
- * 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.
- * Six weeks before release: QA checks on snapshot doc builds, inspect status, getting started guide, and install.
- * Four weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes.
- * Three weeks before release: branches/release closed for all library changes except when specific permission given by release manager(s).
- * Two weeks before release: Beta target date. Further betas and/or release candidates as feedback dictates.
+December milestones prior to the day after Christmas week are scheduled a week earlier than indicated. Done to avoid scheduling milestones during Christmas week. 
 
 == Schedule Rationale ==