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

Rob Stewart wrote:

On June 8, 2014 5:16:29 AM EDT, Stephen Kelly 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-specific... 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.