Boost logo

Boost :

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2024-01-10 14:38:41


On Tue, Jan 9, 2024 at 11:49 AM Robert Ramey via Boost <
boost_at_[hidden]> wrote:

> Perhaps it's time to "get serious" about Boost "Modularization".

This statement ignores all the work that has been done and continues to be
done in terms of making Boost modular.

> Basically this would mean that users download just the libraries (and
> their dependencies) they actually intend to use. Of course this would
> be a big project. But we've been working hard to try to move in this
> direction.

Yes, we have "been serious." (And note when I say "we" I exclude myself, as
I have just been busy cranking away at producing individual libraries and
supporting Boost Libraries infrastructure).

> This would in practice eliminate the concept of Boost version 1.84
> etc... and replace with Boost Serialization library version 1, ...
>

Grouping all the libraries together into a single release version (e.g.
1.85.0) which is all tested against each other as a unit, is the only sane
development model. Otherwise we run into the combinatorial explosion of
questions like "what version works with what." And furthermore,
"eliminating the concept of Boost version ${X}" pushes more testing and
documentation work (to explain what versions work with what) onto each
individual author instead of centralizing that effort into the release
process. I don't like this at all.

Boost would migrate from being a single/monolithic library to a group of
> libraries with some explicit dependencies (on other boost librarys,
> standard library or ?).
>

Boost is already a "group of libraries with some explicit dependencies." It
just so happens that they are bundled together into one archive. Whatever
it is that you are proposing would be in addition to and not in lieu of
what we have.

> The fact that we can't do so now is a symptom that our development
> practices need work.
>

I think this is overlooking the fact that the Boost release process *works
well* right now. Three releases every year like clockwork and they are
pretty high quality in terms of having minimal inter-library defects.

Thanks

On Tue, Jan 9, 2024 at 11:49 AM Robert Ramey via Boost <
boost_at_[hidden]> wrote:

> On 1/7/24 8:48 AM, Glen Fernandes via Boost wrote:
> > Rather than emails and Slack DMs, I would prefer we have this discussion
> > on the mailing list.
> > > It is correct that JFrog does not charge us yet but our traffic has
> > increased from 60TB/month to almost 200TB/month which is no longer
> > supportable for free. We have limited time to find a solution.
> >
>
> Perhaps it's time to "get serious" about Boost "Modularization".
> Basically this would mean that users download just the libraries (and
> their dependencies) they actually intend to use. Of course this would
> be a big project. But we've been working hard to try to move in this
> direction. I would envision:
>
> a) user interested in boost download and locally test Boost "core"
> b) for each library that a users is immediately interested in:
> downloads, builds and tests the library (and it's dependencies)
> c) as time moves on, users could update, replace, or delete their set of
> libraries.
>
> This would in practice eliminate the concept of Boost version 1.84
> etc... and replace with Boost Serialization library version 1, ...
> Boost would migrate from being a single/monolithic library to a group of
> libraries with some explicit dependencies (on other boost librarys,
> standard library or ?).
>
> The fact that we can't do so now is a symptom that our development
> practices need work.
>
> Robert Ramey
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Regards,
Vinnie
Follow me on GitHub: https://github.com/vinniefalco

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk