Re: deprecated: MPL, foreach, typeof, ratio, chrono, assign, more?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-10-05 21:43:33

On 10/5/24 23:56, Vinnie Falco wrote:
> 
> One idea which just came to me while typing this: we remove the library
> from the release but keep the repository on GitHub. Users who need the
> obsolete library can obtain it using this "modular boost" system, or
> using a package manager (or maybe these are both the same thing?) I'm
> not sure how the testing would work. Who would test the obsolete
> library? Maybe that responsibility passes to the author or maintainer.
> Do obsolete libraries receive version tags? All good questions, and I'm
> happy to hear everyone's thoughts.

IMHO, a library either is part of Boost or isn't. There is no middle
ground. If a library is part of Boost then other libraries may depend on
it and it gets tagged and released alongside other libraries in a Boost
release.

You could consider removing leaf libraries from Boost (i.e. those on
which no other Boost libraries depend), so that at least a Boost release
is working. Of course, we would have to consider whether that would
significantly affect Boost users, and whether there are ways to mitigate
those effects, but a consistent Boost release is a mandatory
requirement. But I don't think any of the libraries you mentioned
qualify as leaf libraries, which makes their deprecation rather dubious.

If your goal is to steer users to the more modern alternatives and not
removal then this is different from deprecation. We should be careful
with the language we use in this case, since the alternatives may not
cover 100% of the functionality of the older libraries, and we should
make it clear that it is fine to use the older libraries if the user
needs it. I.e. we should make it clear that the library isn't going
anywhere and is tested and working (to the best of our abilities). For
this reason, I don't think placing a simple "deprecated" or "obsolete"
tag on the library page is a good idea, as it sends the wrong signal.

A better solution would be to add a note or a section in the front page
of the library docs saying something like "if you want A, B and C in a
modern C++ version, you may want to consider library X instead."