| 1 | | = Release Schedule = |
| 2 | | |
| 3 | | == Release Dates == |
| 4 | | |
| 5 | | * Spring release on the second Wednesday of April. |
| 6 | | * Summer release on the second Wednesday of August. |
| 7 | | * Fall/Winter release on the second Wednesday of December. |
| 8 | | |
| 9 | | == Release milestones == |
| 10 | | |
| 11 | | '''Note well: Changes must always be committed to trunk and be stable on trunk regression testing before being merged to branches/release.''' |
| 12 | | * 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.''' |
| 13 | | * 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. |
| 14 | | * Seven weeks before release: Release managers begin QA checks on snapshot doc builds, inspect status, getting started guide, and install. |
| 15 | | * Six weeks before release: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. |
| 16 | | * Five weeks before release: branches/release closed for all changes, except by permission of a release manager. |
| 17 | | * Four days before beta release: branches/release closed. Release managers begin building release candidates. |
| 18 | | * Four weeks before release: Beta release. |
| 19 | | * Upon Beta release: branches/release open for bug fixes and documentation updates. Other changes by permission of a release manager. |
| 20 | | * One week before release: branches/release closed for all changes, except by permission of a release manager. |
| 21 | | * Four days before release: branches/release closed. Release managers begin building release candidates. |
| 22 | | |
| 23 | | December milestones prior to the day after Christmas week are scheduled a week earlier than indicated. Done to avoid scheduling milestones during Christmas week. |
| 24 | | |
| 25 | | == Schedule Rationale == |
| 26 | | |
| 27 | | The quarterly schedule is based on mailing list discussions and the results of a straw poll at the BoostCon '08 "Future of Boost" session: |
| 28 | | |
| 29 | | How often do we want to have Boost releases? |
| 30 | | |
| 31 | | 4 weeks: 0 votes, 6 weeks: 0 votes, 8 weeks: 10 votes, 12 weeks: 25 votes, 16 weeks or longer: 6 votes |
| 32 | | |
| 33 | | The 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. |
| 34 | | |
| 35 | | 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. |
| | 1 | Superseded by [https://github.com/boostorg/boost/wiki/Release-Schedule this]. |
