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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk