Re: [boost] Guidelines to implement Boost library evolution policy (was Boost 2.0)

Subject: Re: [boost] Guidelines to implement Boost library evolution policy (was Boost 2.0)
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-06-08 09:51:15

On 6/8/2014 6:46 AM, Stephen Kelly wrote:
> Rob Stewart wrote:
>
>> On June 8, 2014 5:16:29 AM EDT, Stephen Kelly <hello_at_[hidden]> wrote:
>>> Rob Stewart wrote:
>>>
>>>>> The Jeff Garland case study tells us that the past problem is already
>>>>> solved
>>>>> using Boost from the present or the past. You don't need to solve
>>> that
>>>>> problem again.
>>>>
>>>> Who was suggesting that?
>>>
>>> The author of the document about the future of Boost currently being
>>> discussed.
>>>
>> >From the document:
>>>
>>>> ... illustrates why Boost continues to support older compilers and
>>>> standard libraries
>>>
>>> And it then illustrates that 'older' means 1996 era compilers.
>>
>> As you said, that problem is already solved. There's nothing that must be
>> done to solve it. The point is that creating a new version of Boost with
>> no support for old platforms does not provide a transition to the brave
>> new world of C++11, 14, and beyond.
>
> Migrating to that brave new world requires modularization. Otherwise
> foo_library can not bump its compiler requirements unless that's ok for all
> of its dependees.
>
> Given the current cyclic dependencies that is a real blocker for everything
> in the strongly connected graph. So the current work on removing those
> cycles will prove useful to this discussion.
>
> Also, I urge you not to think in terms of language standards. Think in terms
> of compiler versions and their features.

Realistically this requires a knowledge of particular compilers and 
their versions that it is nearly impossible for any particular developer 
to have. Am I really expected to use or not use a C++ language feature 
in a particular release of my theoretical library because Compiler X, 
version Y does or does not support some C++11/C++14 feature ? I do not 
believe such thinking is conducive to expert programming.

OTOH I agree with you that it is realistic for some version of a library 
to say that older and/or non-compliant compilers/versions which do not 
support C++ feature X are not usable with version Y of a library. So 
that if the end-user is still using that compiler/version they must use 
some earlier version of the library ( or not use the library at all if 
it is a new library using some advanced C++ feature to accomplish what 
it needs ).