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.