Release Process

Boost libraries are released together and publicly three times per year:

  • 2nd April

  • 2nd August

  • 2nd December

Each release will contain updates to existing libraries, and some releases will contain new libraries. The release is built from the Boost GitHub site:

Preparing for a Boost Release

When a release approaches, there is a strict policy on how to merge additions or changes into the library repository. Library maintainers work to prepare their libraries for the release, which involves updating documentation, fixing bugs, and addressing any compatibility issues. Additionally, library maintainers ensure that their libraries pass the Boost regression tests, which help identify potential problems before the release.

As a release date approaches, there are increasing restrictions on what can be merged, to ensure stability.

Regression Testing

Regression testing is an essential part of the release process, ensuring the quality and compatibility of the libraries. The Boost community maintains a set of regression tests, which are run on a diverse range of platforms and compilers. The tests are performed by volunteers who contribute their computing resources to the project.

The results of the regression tests are published on the Boost website, providing library maintainers and users with up-to-date information about the library’s compatibility and performance. Library maintainers use this information to identify and fix any issues before a release.

Beta and Final Release

There is a strict countdown to a public release. Four weeks prior to the release date the Beta release is published to the Boost site.

If issues are found with a release that has gone public, and the issues are important enough to address quickly (that is, before the next full public release), then a point release will be built when fixes are available and tested.

See Also

For details of the Release Process that are pertinent to contributors, refer to the Contributor Guide Release Process.