Releases: Schedule

Release Schedule

Release Dates

• Spring release on the second Wednesday of April.
• Summer release on the second Wednesday of August.
• Fall/Winter release on the second Wednesday of December.

The dates for specific releases and the milestones are posted to the Boost calendar before each release.

Release Milestones

Seven weeks before release:

Release, i.e. master, closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries.

Release managers begin QA checks on snapshot doc builds, inspect status, getting started guide, and install.

Six weeks before release:

Release, i.e. master, closed for major code changes. Still open for serious problem fixes and docs changes.

Five weeks before release:

Release, i.e. master, closed for all changes, except by permission of a release manager.

Four days before beta release:

Release, i.e. master, completely closed. Release managers turn off updating of master branch, or have already done so. Release managers begin building release candidates.

Four weeks before release:

Beta release. Release managers provide release archives at the release web site. The release of the beta can happen earlier than this, but no earlier than one week before at the discretion of the Release managers.

Upon Beta release:

Release, i.e. master, open for bug fixes and documentation updates. Other changes by permission of a release manager.

One week before release:

Release, i.e. master, closed for all changes, except by permission of a release manager.

Four days before release:

Release, i.e. master, completely closed. Release managers begin building release candidates.

Release:

Release managers provide release archives at the release web site.

After the Release managers determine that there are no unforeseen problems in the release the master branch is open again for all changes.

Rationale

Once upon a time, in Spring 2008, it was decided that Boost should formalize the release schedule to four releases a year. This was after taking a poll of BoostCon attendees.

After some experience with the new release schedule, and much hair pulling, in early 2015 the then Release team decided that schedule was too cumbersome to work out for everyone. And instead dediced to switch to an uneven three per year schedule for the following reasons:

• Allows for the fact that most people are on extended holidays during Winter.
• Allows for people to work on larger changes that require more testing time during the longer Winter period.
• Wednesday releases, instead of previously Mondays, allow the release managers non-weekend time to work before and after the release.
• Avoids most common holiday periods.
• Provides for a release shortly before c++now conference. But not short enough to allow for slippage.

The specific timings of the times of the release milestones have changed over time as the Release team in response to community feedback made adjustments to the release process.