[boost] Boost 2.x - (Was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*)

Subject: [boost] Boost 2.x - (Was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*)
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-05-22 14:28:28

Le 21/05/2016 à 18:09, Edward Diener a écrit :
> On 5/21/2016 11:52 AM, Vicente J. Botet Escriba wrote:
>>
>> Wether we want a "C++14 only" Boost  version is another thing.
>
> What could it possibly achieve to have a Boost with only C++11 or 
> above libraries or a Boost with only C++14 or above libraries, as 
> opposed to having Boost as we have it now in which each library can 
> choose what level of C++ support it requires ? I would really like to 
> get a technical answer, as opposed to an emotional response about 
> "moving forward" and "looking to the future" and "serving the entire 
> C++ community", to that question by those who propose such ideas.
>

I'm not saying that Boost 1.x must be stopped. Not all the members of 
the Boost community have the same needs. In particular, I could need a 
C++98 Boost version at work, but I would appreciate a C++14 at home. I 
have moved recently to a project using C++11 and Boost. I will comeback 
to you with my experience.

Starting a new Boost version supporting only new compilers has two 
sides: starting a new version and on new compilers.

What I would expect from a new Boost 2.x version?

* That avoids the issues we are facing with the current Boost 1.x version.

Modularity

    * That it is modular
    * That libraries manage their own version (Major.minor.patch)
    * That libraries manage the dependencies to other libraries without
    cycles.
    * That the included libraries ensure ABI compatibility between minor
    versions (I don't know how to check this)
    * That we manage library and point/patch versions.

Delivery

    * That the whole Boost manages their own version also
    (Major.minor.patch)
    * That we are able to deliver independently Major, minor and patch
    versions.
    * A patch version could consists in upgrading all the libraries to
    its last patch version respecting the Major and Minor versions and
    respecting the dependencies.
    * A minor version would upgrade only the libraries with minor
    versions and respecting the Major version and the dependencies.
    * A Major version would upgrade all the libraries respecting the
    dependencies.
    * This means that we will need to test 3 new release branches.

* Build

    * That we can build all with CMAKE (as it is a standard de-facto).
    * Other build systems could be used as well (as far as they can be
    installed independently)

* Install

    * That we are able to install the libraries independently or as a whole.

* Quality

    * That we ensure some quality KPIs. We would make use of anything
    available to us as static checkers, sanitizers, rules checkers, code
    coverage, profiling,  ....

* Ownership and evolution

    * That we work as a whole, a library shouldn't be owned only by its
    initial author. We need to avoid unmaintained libraries.
    * That any additional features are reviewed to ensure the quality we
    require.

...

What I would expect from a new Boost 2.x version requiring C++11, C++14 
or C++1z compiler support?

* don't reinvent the wheel.
* that it is adapted to the new compiler and library version, e.g. move 
semantics, initializer_list, constexpr, noexcept,  ....
* that it would help to identify possible issues on the standard, the 
compilers and standard library implementations.
* that there is a C++ standard proposal that follows the acceptance of a 
library into Boost, either by the author or someone else ... The 
feedback from the Boost reviews is not the same than the feedback from 
the committee.
* I would appreciate to have the C++14 library additions that don't 
depend on any additional C++14 language feature to be available for 
C++11 compilers in the form of an extension library (we couldn't be able 
to modify classes existing in C++11, but we could add new ones). The 
same applies for C++1z and  C++11/C++14 compilers. This should help as a 
bridge between language versions.

You may have other expectations.

What the authors of such libraries could gain?
* I guess that supporting less compilers would allow to have a library 
code that has less portability issues and that it is easier to maintain.
* C++11/14 offers a lot of things that helps to simplify the code "less 
code more software".
* ...

And last, what the user of such a library could gain?
* a library that works better with the new standard library
* able to install the libraries independently
* less bugs ( remove all the ones related to portability )
* ...

Maybe it is worth having a new Boost 2.x version for C++98 that respects 
the Boost 2.x expectations (I have no time to work on this).

I repeat myself : whether we want to do it is another question.
Is it worth doing it? I don't know. It needs a lot of resources and energy.
What we as a Boost community could lost having additionally these new 
Boost versions?

Best,
Vicente