| | 1 | = Release Schedule = |
| | 2 | |
| | 3 | == Next Release == |
| | 4 | |
| | 5 | == Future Releases == |
| | 6 | |
| | 7 | Releases are scheduled for the last day of the first month of each quarter: |
| | 8 | |
| | 9 | * January 31 |
| | 10 | * April 30 |
| | 11 | * July 31 |
| | 12 | * October 31 |
| | 13 | |
| | 14 | Release milestones |
| | 15 | |
| | 16 | * One week after prior release ships: branches/release opens for all stable changes, including bug fixes, major library upgrades, and, with permission, new libraries. Breaking changes should be coordinated with libraries affected. |
| | 17 | * Six weeks before release: branches/release closes for new libraries and major upgrades or breaking changes to existing libraries. Still open for bug fixes and minor changes to all libraries. |
| | 18 | * Four weeks before release: branches/release closes for routine minor changes and fixes. Still open for serious problem fixes. |
| | 19 | * Three weeks before release: branches/release closes for all library changes except when specific permission given by release manager(s). |
| | 20 | * Two weeks before release (sooner if possible): Beta 1 target date. Further betas and/or release candidates as feedback dictates. |
| | 21 | |
| | 22 | == Schedule Rationale == |
| | 23 | |
| | 24 | The quarterly schedule is based on mailing list discussions and the results of |
| | 25 | a straw poll at the BoostCon '08 "Future of Boost" session: |
| | 26 | |
| | 27 | How often do we want to have Boost releases? |
| | 28 | |
| | 29 | 4 weeks: 0 votes, 6 weeks: 0 votes, 8 weeks: 10 votes, 12 weeks: 25 votes, 16 weeks or longer: 6 votes |
| | 30 | |
| | 31 | The last day of the month is chosen rather than the first day, because January 1st |
| | 32 | comes after a holiday period in which it is hard to get anything done. |
| | 33 | |
| | 34 | The 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. |
