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

Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2018-10-24 19:58:16

On 2018-10-24 03:12 PM, Niall Douglas via Boost 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?

I'm not sure whether I'm thinking too much about implementation details 
here, but I expect this to imply a repo fork (or at least a separate 
branch) of my libraries, so I can strip off support for 
no-longer-supported language variants. And I assume that by "distro" you 
mean a set of releases built from those forks, rather than the current 
set of repos. Correct ?

My answer is "yes".

> 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?

By all means, a separate one ! (Isn't the whole point to strip off 
legacy support ?)

> 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?

That depends on the library and the existing amount of legacy support. 
In either case I'd keep support for "Boost 1", at least until I get a 
sense that all users of the library have moved to the new "Boost 2" version.

>   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'm not sure how to interpret the question. It's possible I'd share 
bugfixes among both versions, but otherwise they would evolve more or 
less independently. (Very likely the "Boost 1" version would move into a 
strict "maintenance mode", without any actual development, as that would 
presumably move to "Boost 2" only.)

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

This question implies to many assumptions for me to answer in simple 
terms, so let me step back a little:

The only way forward, *in particular* if we bootstrap a "Boost 2", would 
be a fully modular set of libraries.
The choice of build system will be up to individual library projects, as 
would the choice of minimal C++ standard.
Further, a particular set of flags used to produce binary releases 
(including what C++ standard feature is used) isn't particularly 
important, at least as far as the definition of the project itself is 
concerned. It may however be restricted by the set of standards that are 
actually supported.

> 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)

I don't expect both Boost versions to coexist in a single translation 
unit. Any versioned namespace seems fine, as I can alias it in user code.

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

None. Boost should be fully modular, and if we can't manage to do that 
for "Boost 1", we should at least start "Boost 2" with full modularity 
right from the start, and build-level requirements should be 
communicated in a build-system-agnostic way.

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

Such integration is a nice-to-have feature, but shouldn't be handled 
centrally. (Modularity & autonomy !)

> 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.

official releases in the long term. (Obviously, to get there and to 
establish a stable cadence will take time)

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

As previously, that shouldn't be a centrally managed concern. 
Documentation should be up to individual library projects.

> Q9: What are your feelings towards the use of Python to script
> infrastructure and tooling in any Boost v2.x?

Python ! :-)
>   For example, Python to run
> a local HTML server to serve documentation locally, or Python to build a
> release etc

These are implementation details we shouldn't be concerned with. 
*Please* learn from past errors and don't reinvent tools (and 
infrastructure) unless you absolutely have to. For now, github and its 
tools and support services are totally sufficient. And even if we have 
to move, let's not start a Big Unified Discussion On Tooling Again !!

> 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?

That's an interesting question. In the projects I'm currently involved 
in (Boost.Python, Boost.GIL, Boost.uBLAS) we are trying to (slowly) 
replace dependency on core components by C++11 equivalents (from 
type_traits over shared_ptr etc.), and I'm not sure what dependencies 
will remain once that endeavor is finished.

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

Stefan

--
       ...ich hab' noch einen Koffer in Berlin...