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

Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-10-24 19:19:31

And answering my own questionnaire ...

> Q0: Are you willing to do the work to adapt your library for any Boost
> v2.x distro if it were to happen?

I am willing.

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

I would like a new separate Boost v2.x distro in addition to the v1.x
distro.

> 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 would keep different editions of Outcome in each, with different
configuration and defaults.

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

C++ 17, as that is where surveys say the userbase is moving to from C++ 11.

> 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'd prefer the inline namespace.

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

Probably cmake. I could be convinced with Build2, if it spat out
exported targets for cmake consumption.

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

Yes I think they should. As a header only library, Outcome is very easy
to integrate into any package manager, indeed it's already built-in to
godbolt.

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

Initially speaking, I think the rolling release suits best at the
beginning. As things stabilise and mature, then proper releases seem
appropriate.

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

Definitely local HTML server. Static HTML is so 1990s.

> 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

I think it should be standard choice. I know that requires a Python
installation on people's machines to build, read docs, or indeed do much
at all, but I think devs should get over it.

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

In my case, I have no hard dependencies on Boost at all. Though I'd like
Boost.Config and Boost.System ported over if possible. And maybe
Boost.Exception.

Niall