Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries

Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: Michael Ainsworth (michael_at_[hidden])
Date: 2015-05-13 18:43:46

The quality of C++ code in Boost is unmatched, and the Boost website attributes this to the review process. So while I see “dangers” in modularising Boost (in that it may cause version-compatibility problems), I also see that it is a separate issue to the review process, albeit one that has an impact on it. The “umbrella organisation” concept as fitting in quite well with the idea, but I do believe that there should also be an “umbrella project”.

As previously mentioned, git submodules can help track dependencies, and this could be used advantageously.

For example, say there is Boost.ProjectA located at git_at_[hidden] <mailto:git_at_[hidden]>:Person_A/Boost.ProjectA.git which depends on Boost.ProjectB located at git_at_[hidden] <mailto:git_at_[hidden]>:Person_B/Boost.ProjectB.git. If ProjectA 1.2 requires ProjectB 3.4, then ProjectA can simply specify that as a submodule. That part is simple. The complicated part is configuring all the dependencies of all the components within Boost.

So is it possible that an umbrella project located at git_at_[hidden] <mailto:git_at_[hidden]>:Admin/Boost could reference both submodules? In such a case, the release process would have to undergo changes, such as follows:

The (example) Umbrella Boost project is at 2.0 and 2.1 in the works.
Person B informs Admin that there are significant improvements in Project B version 3.5, and he wants them included in the upcoming Umbrella 2.1 release.
Admin knows that Project A depends on Project B, and so informs Person A that they are required to ensure Project A is compatible with Project B version 3.5 in order to be included in the Umbrella 2.1 release before date X.
If Project A is not compatible by date X, one of several options could occur:
Project A is dropped from Umbrella Boost 2.1 (this could would mean projects can “come and go” from Boost as compatibility changes).
Project B remains at version 3.4, and Project A remains in Umbrella Boost 2.1.
The Umbrella Boost 2.1 release could be delayed.
When Umbrella Boost 2.1 is released, it simply has updated submodule dependencies.

(In the above, don’t get distracted by the fact that I’ve used GitHub as an example - yes, it’s a commercial company, but Git is distributed so it doesn’t matter where the code lives; there could be a remote repository called “official” on git.boost.com).

The above process is similar fashion to how yum and other package managers work in an operating system release. I’m new to Boost, but I hope the above suggestion might give others with a much better understanding of the situation some ideas in order to decide on a course of action.