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: Edward Diener (eldiener_at_[hidden])
Date: 2015-05-13 14:12:26

On 5/13/2015 1:24 PM, Thijs (M.A.) van den Berg wrote:
>
>
>
>
>> On 13 May 2015, at 19:00, Edward Diener <eldiener_at_[hidden]> wrote:
>>
>>> On 5/13/2015 12:37 PM, Stefan Seefeld wrote:
>>>> On 13/05/15 12:19 PM, Niall Douglas wrote:
>>>> Personally speaking, I think the new library authors are
>>>> overwhelmingly voting for a complete break with Boost 1.x. It makes
>>>> no sense to bundle these new libraries into a 1.x monolithic distro
>>>> when they have no dependencies on Boost.
>>>>
>>>> I believe now is the time we start establishing the infrastructure to
>>>> shape the new Boost 2.0 distro instead of wasting resources on trying
>>>> to refactor the 1.x distro. APIBind is there for maintainers wanting
>>>> to be part of both distros. Let's make a clean break.
>>>
>>> Allow me to bring up a point I have been trying to make for quite a
>>> while: Why does Boost need a single "distro" ?
>>> Assuming a full breakup of boost libraries with well documented (and
>>> encoded) dependencies among them, I think a much more viable solution
>>> for everyone would be to let each boost library become its own project
>>> with its own release schedule etc.
>>>
>>> So Boost would be merely an umbrella organization, and what you call a
>>> distro may be the repository of Boost libraries.
>>>
>>> Wouldn't that be something worthwhile to think about and discuss ?
>>
>> It is definitely worth discussing. The key is "with well documented (and
>> encoded) dependencies among them".
>>
>> How do we do this ? '
>>
>> It is silly to suppose that new "Boost" libraries will be developed that do not depend on other already existing Boost libraries. If library X depends on library Y we currently know that library X will work with library Y for Boost distro N because we have tested them before we release distro N. If library X goes off with its own release schedule how do we determine with which versions of Y it will work when it is being released ?
>>
>> This is the crux of the matter if we have individual Boost libraries being released on their own.
>>
>>
>
> There wouldn't need to be a "we" to determine that. X version 1 (X1) would depend on Y1, when Y upgrades to Y2 then it's up to X to check if X1 works with both Y1 and Y2 or just Y1. If not then it could make a X2 release to support both Y1 and Y2.

So for each library you want the library maintainer to periodically 
check every past and present version of a library it depends on and 
document what dependencies it has and what versions of those 
dependencies works with the library.

Forgive me if I find such a task a bit overburdening. This means that if 
my library X depends on A, B, and C I must test my library first against 
past versions of A, B, and C, in all possible combinations, and then 
must susbsequently test my library against any new versions of A. B. and 
C, in all possible combinations. Furthermore whenever I update library X 
I must go through the full procedure once again.

I cannot conceive that such a manual versioning scheme is workable.