Testing Javascript disabled
Version Control Boost uses the Git version control system for its development. This allows multiple contributors to work on the libraries concurrently, while keeping track of the changes that each person makes. Git is a distributed version control system, which means each contributor has their own local copy of the entire project, including its history.
This section covers:
Library Repositories
The Super-project Repository
Breaking Changes
Issues and Discussions
Library Repositories The Boost libraries are modular, and each library has its own separate repository. This makes it easier to work with the entire collection of Boost libraries.
The official Boost repositories are hosted in GitHub under the https://github.com/boostorg/ account. Each library has its own repository under this organization. For example, https://github.com/boostorg/json for Boost.Json, or https://github.com/boostorg/date_time/ for Boost.DateTime.
As with any Git-based project, you can clone the repositories, make changes, commit those changes to your local repository, and push your changes back to the server. If you want to contribute changes to the official Boost libraries, refer to Contribute to an Existing Library.
The Super-project Repository The Boost Super-project repository includes all the libraries as submodules.
In addition to the libraries, you’ll find many other repositories under boostorg that handle other tasks, for example:
boost/tools includes B2 sources in build, and CMake support
Release tools
The Super-project has both master and develop branches, which operate somewhat differently than for individual libraries.
New features are added and bugs are fixed in library develop branches. When the develop branch passes its' merging criteria (Continuous Integration, projects are built correctly, other test processes run without errors, etc.), it is merged with the library master branch.
For the Super-project, the develop and master branches are independent. Both branches track the latest changes in the corresponding library branch, for all libraries. The Super-project branches are never merged, as this strategy prevents merging. In other words, the Super-project master branch is created from the library master branches, not from the Super-project develop branch (which is primarily used for testing).
When there is a public release of Boost, it is built from the master branch after that branch has been closed to updates (refer to the Release Process).
Working with the Super-project Usually, a submodule in the Super-project will be created for a library developer by a staff member of Boost.
Recall that, in Git, when a submodule is added to a project, the submodule references a particular commit. This means that, when developers update their sub-projects, the Super-project doesn’t get immediately updated. For this reason, there is a commit bot that runs every 15 minutes and updates the commit to which each submodule references in the Super-project. This happens for both the develop and master branches.
As you update your library, and the Super-project develop branch is updated by the commit bot, you may affect other developers. For example, if a mistake is made to the MySQL library develop branch, then it will affect the CMake module, because this module runs tests to verify that you can use MySQL via CMake.
As part of Boost testing, Continuous Integration (CI) usually clones the Super-project and any required submodules.
When testing any branch that is not master, the develop branch of the Super-project is cloned.
When you’re testing master (which could be for a release), the master branch of the Super-project is cloned.
While this cloning process is not a requirement, most libraries follow it.
If you need to look at the code for the 1.82.0 release, navigate to the relevant repo, and enter:
git checkout boost-1.82.0