On 10/24/18 12: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?
any ? hmmm - couldn't promise that.
Q1: Would you prefer a new, separate Boost v2.x distro in parallel to the v1.x distro,
no or to keep everything within one v1.x distro? Just cherry pick the boost libraries you want use in your v2.x fork. You don't even have to aske me.
Q2: Would you be intending to keep your library inside Boost v1.x, yes move it exclusively to Boost v2.x, no or have it exist in both Boost v1.x and v2.x but with different defaults configured? as I said, just create your own fork. You can a) post PRs to the "golden copy" b) change whatever you want c) Merge changes in the "golden copy" back into your fork before you "release" or whenever convenient.
Also, would the version in v1.x be hard forked from any v2.x edition i.e. the v1.x edition would get orphaned? no - you or anyone else can fork from it for any desired reason. The golden copy in my case will always be compatible with all versions of C++03 .. ? Of course if you want to use it as part of an application you'll have to compile your copy with the same compiler your application is using. You're totally free to do that and can expect it to work.
Q3: What C++ standard should Boost v2.x's master build system be defaulted to? C++ 11, 14, 17 or 20? whatever you want. It's still a free country.
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)
The golden copy will use the current namespace. If you wanted you could probably wrap the headers to effectivly change them. But if I were you I wouldn't do that as it would entail nothing but grief. Another thing you could it is just global replace all the namespace names boost to boostv2. Remember (I believe) you'll always be able to merge the golden copy back into your local one.
Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake, Build2, something else?
whatever works best for you.
Q6: Should Boost v2.x's libraries auto integrate individually into some package manager? If so, which ones do you intend to support?
again. whatever works best for you. Were you to conjure up something of value in boost v2 - and we ask you to do it - feel free to create a PR so we can use it in the "golden copy"
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.
again whatever works best for you. feel free to experiment.
Q8: Should Boost v2.x use a local HTML server to serve documentation, and the static HTML docs be dispensed with as a requirement?
you could do that on v2 however you want. This question is actually interesting however. Personally I've advocated that every library have statically defined BoostBook or quickbook documentation and from that generate on demand documentation in html, singlepage html, and PDF using the boostbook system. I've also argued that the static web pages built either by hand or via the boostbook system should be part of the library. My main reasons are modularity and regularity as not all documentation is made with boostbook. This is historically a stick subject and will continue to be.
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
oh - one more language to learn - just to release. No thanks. I'm kind of busy.
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?
mpl, iterators, sprite, and likely a lot more.
I could go on, but let's stop there for now.
You're welcome. Robert Ramey
Niall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost