Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-02-04 13:34:09


On 2/4/23 16:26, Glen Fernandes via Boost wrote:
> On Sat, Feb 4, 2023 at 7:08 AM Peter Dimov wrote:
>
>> This proposal should ultimately be approved and
>> implemented by the Boost release managers; their
>> opinions are particularly appreciated.
>>
>>
> We're having the release manager discussion about this off the list but I
> just wanted to let people know that we are discussing it.
>
> I am personally in favor of:
>
> - No longer letting C++03 failures block the release
> - This means giving those core Boost libraries (that are just keeping
> C++03 support because other Boost libraries depend on them) the freedom to
> drop C++03 support.
>
> I think we would wait at least two versions from the announcement, i.e. at
> least after Boost 1.83 for the first Boost release where we drop the
> support. This for both: Those distributions that ship Boost and update
> their Boost version every 6 months or so, and: Giving authors that extra
> time to get whatever they want in for the final "C++03 supporting" Boost.
>
> The major version number increment when we do this is also appealing to me.
> A further idea which was raised off list, and worth hearing the developer
> community's opinion on, is:
>
> - When we go to version 2.0, Boost libraries would have to "opt in" to
> being part of the Boost collection. All this means is that those libraries
> who do not have active maintainers would not opt in, and would not ship in
> Boost 2.

Is the goal to drop C++03 or unmaintained Boost libraries? Those are two
different goals.

Personally, I don't think dropping any Boost libraries, even
unmaintained ones, benefits our users. Especially not, if it is
impossible to use Boost 2.x and 1.x in the same code base. And I suspect
that we don't want to mess with changing namespaces and macro names,
which means 1.x and 2.x are mutually exclusive in the same code base.

So, in my opinion, all libraries must be in 2.x by default. Any
exceptions to that should be discussed individually.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk