Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2018-10-24 20:04:09

On Wed, Oct 24, 2018, 21:40 Antony Polukhin <antoshkka_at_[hidden]> wrote:

>
>
> On Wed, Oct 24, 2018, 21:30 Niall Douglas via Boost <boost_at_[hidden]>
> wrote:
>
>> > But we can't just stop investing effort in C++03 maintenance. We have to
>> > officially drop C++03 at the Boost level, meaning, refuse to compile
>> > Boost with C++03 at all, or make it difficult, or at least make it
>> > choose an intelligent default that is never C++03.
>>
>> As Beman suggested so many years ago now, it's long overdue for a
>> separate Boost v2.x release which is shorn of the backwards
>> compatibility and undermaintained libraries.
>>
>> I'd make it C++ 17 by default, too, as surveys suggest people are
>> jumping straight from C++ 11 to C++ 17 and not stopping at C++ 14.
>>
>> People can keep around Boost 1.x with the existing libraries as long as
>> people want it. Let's just break free of the ancient cruft already.
>>
>> And before anyone asks, it would be on each individual library
>> maintainer to do the work to put their library into Boost 2.x.
>>
>
> I'm in. Let's do that.
>

I gave it another thought and now I do not like that idea.

At first it seems tempting to drop a big pice of legacy libraries and leave
only the most fresh ones. Let's put aside the difficulty of choosing the
right library set for a moment, we have bigger problem here.

The problem is that such approach is not user friendly at all. Even if we
choose some optimal criteria for Boost2 libraries, there'll be always some
users that wish to see one more ancient library in the new Boost. By taking
the responsibility to choose the criteria we do not give users any way to
affect the library set.

What's more bad - we'll have to repeat the procedure each 10-30 years. And
the procedure is probably require a lot of efforts from us and from users
(take a look at the Python2 and Python3 story).

Instead of starting a new Boost we can just deprecate the libraries more
aggressively. Put a note in release notes. Say that the library X is not
maintained and that if there'll be no maintainer in next 2-3 releases then
the library will be removed from Boost. With this approach users can affect
the decision we make. For example, users that are really interested in the
library could become the new maintainers. Or they can hire a person to
support 5-10 libraries for full time.

>