Library devs only: Boost v2.x distro design questions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Library devs only: Boost v2.x distro design questions

Boost - Dev mailing list
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?

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?

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?

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

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)

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

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

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.

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

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

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?


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

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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.

A quick comment upfront: I'm not entirely sure what you mean by "distro"
in your below questions. I have "project", "repository", "release",
"package" in my ontology. Can you relate "distro" to that ? (I'll wait
with my answers to make sure I understand the meaning of your questions.)

Thanks,

Stefan

--

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
> A quick comment upfront: I'm not entirely sure what you mean by "distro"
> in your below questions. I have "project", "repository", "release",
> "package" in my ontology. Can you relate "distro" to that ? (I'll wait
> with my answers to make sure I understand the meaning of your questions.)

Distro = Distribution.

So, specifically, an archive or bundle or git master repo SHA stamp of
specific versions of libraries known to work well together.

In other words, a tarball, a ZIP archive etc, though you don't actually
need that, a git clone of a specific tag in a git master repo is sufficient.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 2018-10-24 03:21 PM, Niall Douglas via Boost wrote:

>> A quick comment upfront: I'm not entirely sure what you mean by "distro"
>> in your below questions. I have "project", "repository", "release",
>> "package" in my ontology. Can you relate "distro" to that ? (I'll wait
>> with my answers to make sure I understand the meaning of your questions.)
> Distro = Distribution.

Yeah, I've heard the term. :-) I just don't know what you mean by it !

> So, specifically, an archive or bundle or git master repo SHA stamp of
> specific versions of libraries known to work well together.
>
> In other words, a tarball, a ZIP archive etc, though you don't actually
> need that, a git clone of a specific tag in a git master repo is sufficient.

Isn't that what we normally call a "release" ? (So if you have a reason
for not wanting to use the term, can you elaborate what the difference is ?)

Stefan

--

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list

>> In other words, a tarball, a ZIP archive etc, though you don't actually
>> need that, a git clone of a specific tag in a git master repo is
>> sufficient.
>
> Isn't that what we normally call a "release" ? (So if you have a reason
> for not wanting to use the term, can you elaborate what the difference
> is ?)

A release, to me, implies humans did validation on it.

A distribution implies that no more than computers did validation on it.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost