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: Stephen Kelly (hello_at_[hidden])
Date: 2014-06-08 06:46:31

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. The year of release of a language 
standard is entirely irrelevant. Consider instead what features are 
available in the set of minimum compiler requirements you have. It is really 
no different to the 'can we use member templates' question.

 http://www.kdab.com/modern-cmake-with-qt-and-boost/#compile-feature-specification

C++ developers probably won't be able to depend on the existence of 
constexpr in portable code before 2020 (ie, until the MSVC release which 
supports it is the oldest MSVC version in widespread use). People need to 
stop thinking about it as a '2011 feature'.

However, you can rely on the existence of other features such as decltype 
and rvalue references whenever MSVC 2010 is the minimum required version 
(I'm not saying you need to bump it to that now) and other minimum 
requirements also support the relevant features.

So, don't frame questions in your mind as 'can we use C++11?'. 

Ask instead 'what are our minimum compiler requirements and what features 
can we rely on from them'.

So, what are the current minimum compiler requirements for Boost? Are they 
sensible? Would a policy which keeps them 'rolling' make sense? Should a 
support for a compiler *ever* be dropped? Robert Ramey seems to think not.

Note that I never suggested a 'big bang' break forward. I suggest only 
modernizing your toolchain/compiler/stdlib requirements and then making use 
of the features that become available as a result.

It is not clear whether the Boost community wants to do that at all. I get a 
lot of emails off-list from people who do want that, but they don't write to 
the list so it's quite useless. Others clearly want no dropping of old 
compiler/stdlib ever. 

If you're creating a document about the future of Boost, compiler/stdlib 
versions is what you need to create a concrete policy about. Instead the 
document discusses C++11/14 and that's the wrong mindset as I note above. 
The language standard is incidental. Think about compiler versions and their 
features.

> There's nothing in that policy that requires support for any particular
> old platform. 

Is 'particular' the operative word here?

> Add always, library authors and maintainers are free to drop
> support for older platforms add they see fit.

After modularization, to some extent, yes.

Thanks,

Steve.