Re: [boost] Library devs only: Boost v2.x distro design questions

Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2018-10-25 06:59:50

On Wed, Oct 24, 2018, 22:12 Niall Douglas via Boost <boost_at_[hidden]>
wrote:

> Splitting this off from the other thread, can I get feedback from Boost
> library maintainers ONLY. Not users, not non-maintainers.
>
> Q0: Are you willing to do the work to adapt your library for any Boost
> v2.x distro if it were to happen?
>

At most half of them.

Q1: Would you prefer a new, separate Boost v2.x distro in parallel to
> the v1.x distro, or to keep everything within one v1.x distro?
>

One distro please.

Q2: Would you be intending to keep your library inside Boost v1.x, move
> it exclusively to Boost v2.x, or have it exist in both Boost v1.x and
> v2.x but with different defaults configured? Also, would the version in
> v1.x be hard forked from any v2.x edition i.e. the v1.x edition would
> get orphaned?
>

I'll keep the remaining half of the libraries in both Boosts. The defaults
will be different. I'll keep maintaining all the libraries.

Q3: What C++ standard should Boost v2.x's master build system be
> defaulted to? C++ 11, 14, 17 or 20?
>

17 at least.

Q4: Should Boost v2.x use a boost2 namespace, or namespace boost {
> inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions
> of your library can be used within the same translation unit)
>

It should be namespace boost { inline namespace v2_VERSION { }} where
VERSION is the minor version of current release. Many people were
complaining that they have to use two different versions of Boost.
Different versions do not link well.

Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake,
> Build2, something else?
>

The most popular ones. Cmake leads right now.

Q6: Should Boost v2.x's libraries auto integrate individually into some
> package manager? If so, which ones do you intend to support?
>

I'd leave the packaging to the package manager authors. We have other
things to do, rather than supporting 5-37 different package managers.

Q7: Should Boost v2.x have official release versions done by release
> managers, or should it be a rolling release of "whatever last passed the
> CI @ 100%"? Note that you can have this, and have official release
> versions of "especially known good" editions too.
>

Same as with Boost1

Q8: Should Boost v2.x use a local HTML server to serve documentation,
> and the static HTML docs be dispensed with as a requirement?
>

Don't care.

Q9: What are your feelings towards the use of Python to script
> infrastructure and tooling in any Boost v2.x? For example, Python to run
> a local HTML server to serve documentation locally, or Python to build a
> release etc
>

Python is a good language.

Q10: What parts of core Boost are you utterly dependent upon, and would
> absolutely need ported to any Boost v2.x as no STL alternatives exist?
>

Asio, intrusive, container, program_options, spirit, predef... too many to
enumerate all of them.

I could go on, but let's stop there for now.
>

The idea of Boost2 is a good idea. But let's move evolutionary, rather than
revolutionary. Deprecate and remove the libraries, set cxxstd=14 by
default, mark outdated/unmaintained libraries with some mark in the docs,
add inline namespaces with version, add modules ts support... In a few
years we'll be able to change the major number to 2.

>