On Wed, Oct 24, 2018, 22:12 Niall Douglas via Boost
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.