I like the checkbox « hide deprecated » : I would find it easier for newcomers to navigate the Boost ecosystem if deprecated libraries were hidden by default. There are already so many libraries to discover … Furthermore, showing deprecated stuff to newcomers may not be the best way to reinforce the image of a modern, still-relevant boost ? Also one must already have some pretty good knowledge of boost if they are seeking a specific deprecated library, so hidding it by default may not be a problem. Best wishes, Arno Le sam. 5 oct. 2024 à 19:33, Jakob Lövhall via Boost a écrit :

...

The website could have a checkbox, "hide deprecated", enabled by default.

I prefer to have a clear indicator that its deprecated rather than making the library difficult to find. A text saying deprecated somewhere early on in the description should do the job.

Den fredag 4 oktober 2024 kl. 20:21, Vinnie Falco via Boost < boost@lists.boost.org> skrev:

...

Should one or more of these libraries be marked as "deprecated" in their corresponding meta/libraries.json?

Array Assign Chrono Compatibility compressed_pair enable_if ForEach functional mem_fn move MPL Ratio ResultOf Typeof

The new website could use this information to annotate the library. We could add a "reason" field to libraries.json which is displayed on the site. The website could have a checkbox, "hide deprecated", enabled by default. We could show the reason for the deprecation. For example, that mp11 is a more modern and functional version of MPL. Or that ForEach is now a C++ language feature.

The authors and maintainers of those libraries would need to opt-in to this, although we could have someone work up pull requests for some or all of those libraries. There might be more libraries that belong on the list, feel free to add.

Another idea we might consider is to add a preprocessor deprecation warning, unless the user opts-in by defining BOOST_ALLOW_DEPRECATED or something. Before we do that though, we should ensure that no non-deprecated Boost libraries are using the above libraries.

Thanks

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

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

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."

I have no opinions yet, currently this is just an information gathering expedition.

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.

I've been meaning to raise this.  How about a procedure something like this: Status 1:  Library is maintained and current.  No change Status 2: Library is a "candidate for deprecation": this is where we ask the question on the mailing list (and perhaps elsewhere), should this library be marked as deprecated?  In order to reach this point then the library must: a) Have no meaningful recent maintenance.  b) Not be a major dependency of other Boost libraries.  c) Not be a major dependency of other active FOSS projects (ie google search shows up nothing).  If the answer comes back as "no" then we should at least try and have a bit of a bug sprint on the library (remember those?) and at least get CI back up to current standards and relevance.  In fact this step alone may be useful in focusing minds on what needs to be done to keep useful but unmaintained libraries alive.  If "yes" to deprecate, then move to status 3... Status 3: Library is deprecated: it should not be used in new code, it's documentation contains a clear admonishment to indicate it's status, and the library is moved into a separate index on the website for deprecated libraries.  It is still shipped as part of the release. Status 4: Former Boost libraries.  After a suitable amount of time deprecated, a library may be formally removed from Boost. This means that: a) we no longer include the library in our release tarballs, b) the library is moved to a new index category for "former boost libraries"  c) we do one final github-only release of the libraries source, users may download and extract over the top of the rest of Boost at their own risk. And finally... There is no such thing as a dead library: any library can be resurrected back up to status 1 by some meaningful maintenance and/or an indication that it is still relevant. Hoping this helps yours, John.

On 10/6/24 4:09 PM, Joel de Guzman via Boost wrote:

On 10/7/24 3:13 AM, Robert Ramey via Boost wrote:

...

On 10/4/24 11:21 AM, Vinnie Falco via Boost wrote:

...

Should one or more of these libraries be marked as "deprecated" in their corresponding meta/libraries.json?

Array Assign Chrono Compatibility compressed_pair enable_if ForEach functional mem_fn move MPL Ratio ResultOf Typeof

I would think that serialization should be added to this list as it uses a lot of "deprecated" libraries and this is not going to change.

You can add "Classic Spirit" to the list: The first generation version Spirit V1.8.

The LTS (C++03) version of Spirit is currently V2.59, and the newest version is Spirit.X3.

FYI - the reason that serialization was never "upgraded" was that as far as I could tell it had a different interface. And since version 1 works forever, there was never any motivation to change the serialization library. FYI2 - My policy is that once something is working, I don't mess with it unless there is some substantive reason to do so. E.G. I wouldn't change anything from one thing to another just because the later is "more modern" Robert Ramey

On 10/6/24 5:06 PM, Vinnie Falco via Boost wrote:

On Sun, Oct 6, 2024 at 4:53 PM Robert Ramey via Boost wrote:

...

FYI2 - My policy is that once something is working, I don't mess with it unless there is some substantive reason to do so. E.G. I wouldn't change anything from one thing to another just because the later is "more modern"

Should Boost have kept C++03?

This question illustrates a lack of understanding regarding C++ backwards compatibility. I have posted an explanation of this at least a dozen times. People don't get it. Here is the LAST time. a) Boost always required that a submission work correctly on the compiler/library standard existent at the time of submission. b) All subsequent versions of C++ compiler/library must be backwards compatible with all previous versions. There have been only a handful of exceptions to this rule in the last 30 years. c) After acceptance, library maintainers may "upgrade" code to a later standard at their discretion. However, they are not required to. It should be obvious why this policy has to be the way it is. Were it not for this policy, many boost libraries would be out of boost compliance with the release of every new version of C++. This would impose a huge unnecessary burden on library maintainers. And we don't have enough library maintainers. d) Hence, a program written to be compatible with C++03 is (almost) guaranteed to function. As far as I know this policy has never changed in the history of Boost. Probably because it makes no sense to do so. The recent effort to "deprecate" support for older compilers was a total waste of time and effort and added nothing to boost. Next topic: Boost Build and the "Modularization" effort .... Robert Ramey

On 10/6/24 5:31 PM, Vinnie Falco via Boost wrote:

On Sun, Oct 6, 2024 at 5:21 PM Robert Ramey via Boost wrote:

...

On 10/6/24 5:06 PM, Vinnie Falco via Boost wrote:

...

Should Boost have kept C++03?

...The recent effort to "deprecate" support for older compilers was a total waste of time and effort and added nothing to boost....

After trimming away the superfluous words, your answer can be stated concisely as "yes" (to keeping C++03)

LOL - any C++03 compatible code is also compatible with the latest version of C++. It is not within anyone's power to "keep" or "not keep" C++03. It's always there and always will be as long as C++ keeps it promise to maintain backward compatibility.

Thanks

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

пн, 7 окт. 2024 г. в 08:02, Robert Ramey via Boost :

LOL - any C++03 compatible code is also compatible with the latest version of C++. It is not within anyone's power to "keep" or "not keep" C++03. It's always there and always will be as long as C++ keeps it promise to maintain backward compatibility.

Since C++03 several keywords have been added or changed meaning, and core language features and library facilities have been removed. There are also things like spaceship breaking code relying on Boost.Operators. So, this statement is not exactly true.

пн, 7 окт. 2024 г. в 19:25, Robert Ramey via Boost :

Right. In another post I used the phrase "(almost)" compatible. I found it tedious, patronizing and pointless to to continue to repeat this. Damn: wrong again.

I wasn't trying to nitpick. Several changes were made to C++ that have made previously written code not compile or behave differently. We just recently discussed how changes to std::optional proposed for C++26 will change the behaviour of Boost.JSON. So, you can't really write some C++ code in 2003 and be sure that it never breaks in a later language version.

On 10/7/24 1:07 AM, John Maddock via Boost wrote:

...

...

Should Boost have kept C++03?

This question illustrates a lack of understanding regarding C++ backwards compatibility.  I have posted an explanation of this at least a dozen times.  People don't get it.  Here is the LAST time.

a) Boost always required that a submission work correctly on the compiler/library standard existent at the time of submission.

b) All subsequent versions of C++ compiler/library must be backwards compatible with all previous versions.  There have been only a handful of exceptions to this rule in the last 30 years.

Actually I disagree, there have been a handful of rather high profile exceptions, which have required quite a bit of maintenance to make code compatible with modern compilers.  The removal of std::iterator and associated base classes being the most painful recent one.

Hmmm - I'm not seeing a disagreement here. Aside - I always used Boost.Iterators so I've never seen this.

...

d) Hence, a program written to be compatible with C++03 is (almost) guaranteed to function.

As far as I know this policy has never changed in the history of Boost. Probably because it makes no sense to do so.  The recent effort to "deprecate" support for older compilers was a total waste of time and effort and added nothing to boost.

It is certainly true that it's pointless to change code that is working well.  However there are circumstances where some modernization is extremely useful, to pick some random examples from Boost.Math:

Right. This is the perview of the library maintainer - if there is one.

* C++11 thread safe static variables are a huge win in code simplification and runtime startup cost (we have lots of tabular data). > * Post C++11 meta programming is a lot easier on the compiler (shorter compilation times) than C++03.

* Post C++17 would let us replace tag dispatching with "if constexpr", which is easier to read and quicker to compile.

* We do occasionally get bug reports along the lines of "this code is so last century, please modernize".  Unless there is a compelling reason to do so we (or at least I) tend to resist until there is other maintenance going on in that file, but generally removing C++03'isms makes the code easier to grok.

Right. But all this is outside of the perview and authority of the "boost technical leadership" - whatever that is.

* Younger programmers (the ones we need to encourage to join) don't have a clue about C++03 style code, and just wonder why the heck you're not using lambda's and auto everywhere etc. Eventually my C++03 code will look like F77 does to me: so hopelessly outdated that no sane person would ever want to work on it.   Sad but true!

Fewer younger programmers inspire me these days.

Best, John.

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

René Ferdinand Rivera Morell wrote:

On Mon, Oct 7, 2024 at 11:37 AM Robert Ramey via Boost wrote:

...

Fewer younger programmers inspire me these days.

Younger programmers are just as capable, and clueless, as I was when at that age. The expectations of the older and older C++ community unfairly expects more than we should be. And in many ways it was easier to "grow up" with the advent of computers and programming.

Age is not the relevant factor here. Forcing people to write C++98 code in 2024 probably violates the Geneva convention.

On 10/7/24 22:16, Peter Dimov via Boost wrote:

René Ferdinand Rivera Morell wrote:

...

On Mon, Oct 7, 2024 at 11:37 AM Robert Ramey via Boost wrote:

...

Fewer younger programmers inspire me these days.

Younger programmers are just as capable, and clueless, as I was when at that age. The expectations of the older and older C++ community unfairly expects more than we should be. And in many ways it was easier to "grow up" with the advent of computers and programming.

Age is not the relevant factor here. Forcing people to write C++98 code in 2024 probably violates the Geneva convention.

Noone's forcing anyone. Writing C++23 or whatever is pretty orthogonal to using any of the libraries that were mentioned in this thread. If anything, declaring core libraries deprecated would force downstream users to seek for alternatives and update their code.

Andrey Semashev wrote:

On 10/7/24 22:16, Peter Dimov via Boost wrote:

...

René Ferdinand Rivera Morell wrote:

...

On Mon, Oct 7, 2024 at 11:37 AM Robert Ramey via Boost wrote:

...

Fewer younger programmers inspire me these days.

Younger programmers are just as capable, and clueless, as I was when at that age. The expectations of the older and older C++ community unfairly expects more than we should be. And in many ways it was easier to "grow up" with the advent of computers and programming.

Age is not the relevant factor here. Forcing people to write C++98 code in 2024 probably violates the Geneva convention.

Noone's forcing anyone. Writing C++23 or whatever is pretty orthogonal to using any of the libraries that were mentioned in this thread.

Maybe I was too curt? My point was that if we want people to contribute to our libraries in 2024, we shouldn't require from them to do so using C++98 code, because that's, well, unpleasant and an outdated skill that nobody should have to acquire. Even C++11's limitations are quite irritating at times, but C++11 is still miles better than C++98. I'm not young, but I would certainly prefer to write C++11 than C++98.

If anything, declaring core libraries deprecated would force downstream users to seek for alternatives and update their code.

The suggestion here wasn't about declaring core libraries deprecated... well, it was, but "obsolete" is a better term than "deprecated". It's about discouraging the use of obsolete libraries in new code. The problem is that when we display the list of libraries, we give no hints to the initiated that a library has been obsoleted by the language (which is the case with Move and Foreach), the stdlib (the case with Bind, MemFn, Ratio, and many others), or by another Boost library (MPL and Mp11.) Yes, this actually happens; people do sometimes choose to use an obsolete library in error just because our list doesn't make the above clearer. (And no, the Serialization library isn't obsolete, because it hasn't yet been obsoleted by anything.)

Vinnie Falco wrote:

What I am proposing is something more fundamental. A deeper treatment of these obsolete libraries. How deep? Well, I don't quite know, hence the reason for the original post. At one extreme there is the idea to no longer include, for example Boost.Move in the release. The repository would not disappear but we wouldn't go out of our way to install it on people's machines.

Well, if that's what you're proposing, then the answer is pretty easy (it's "no".)

On 2024-10-08 02:36, Vinnie Falco via Boost wrote:

What I am proposing is something more fundamental. A deeper treatment of these obsolete libraries. How deep? Well, I don't quite know, hence the reason for the original post. At one extreme there is the idea to no longer include, for example Boost.Move in the release. The repository would not disappear but we wouldn't go out of our way to install it on people's machines. This may not be practical right now given the number of dependees but it still merits thought. At the other extreme we have just marking the library on the website as "obsolete." We should definitely do that.

In a previous posting https://lists.boost.org/Archives/boost/2024/10/258040.php I stated: I don't see why an old C++ library that has no security impact and "just works" cannot live on after being marked deprecated. Now I see a reason why removal might be an option. With 1.86 BGL minimum compiler requirement was raised to C++14. Compilation of 1.86 BGL with C++11 just fails. So if a user of BGL has requirement to use C++11, use of 1.85 or earlier is needed. So similar to "library removal" raising of required C++ version already happens, and as long as the old Boost versions like 1.85 and before keep being available on boost.org, those with need for C++11 have options. Regards, Hermann.

On 10/7/24 5:31 PM, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

On 10/7/24 22:16, Peter Dimov via Boost wrote:

My point was that if we want people to contribute to our libraries in 2024, we shouldn't require from them to do so using C++98 code, because that's, well, unpleasant and an outdated skill that nobody should have to acquire.

No one has suggested that anyone be required to use C++98 code.

The suggestion here wasn't about declaring core libraries deprecated... well, it was, but "obsolete" is a better term than "deprecated". It's about discouraging the use of obsolete libraries in new code. The problem is that when we display the list of libraries, we give no hints to the initiated that a library has been obsoleted by the language (which is the case with Move and Foreach), the stdlib (the case with Bind, MemFn, Ratio, and many others), or by another Boost library (MPL and Mp11.)

Yes, this actually happens; people do sometimes choose to use an obsolete library in error just because our list doesn't make the above clearer.

(And no, the Serialization library isn't obsolete, because it hasn't yet been obsoleted by anything.)

Hmmm - many people have suggested that it's been made "obsolete" by Cereal. Many have suggested using JSON for serialization. It sounds like that the words "deprecated" and "obsolete" haven't been well defined in this discussion and this has created a lot of confusion - at least for me personally. Perhaps the proposed list should look something like: .. ForEach // not recommended for new designs. Use std::foreach instead. ... Serialization // not recommended for new designs. Cereal or Boost.JSON instead. ... thus avoiding using this confusion at its source. Boost could ship with everything it does now in order to support older implementations while not promoting their usage - or even making them publicly visible. Hopefully, this would give the large majority of users a hint that will make their life easier and their experience with Boost better. Robert Ramey

On 10/8/24 14:35, Andrey Semashev wrote:

On 10/8/24 03:31, Peter Dimov via Boost wrote:

...

Andrey Semashev wrote:

...

On 10/7/24 22:16, Peter Dimov via Boost wrote:

...

René Ferdinand Rivera Morell wrote:

...

On Mon, Oct 7, 2024 at 11:37 AM Robert Ramey via Boost wrote:

...

Fewer younger programmers inspire me these days.

Younger programmers are just as capable, and clueless, as I was when at that age. The expectations of the older and older C++ community unfairly expects more than we should be. And in many ways it was easier to "grow up" with the advent of computers and programming.

Age is not the relevant factor here. Forcing people to write C++98 code in 2024 probably violates the Geneva convention.

Noone's forcing anyone. Writing C++23 or whatever is pretty orthogonal to using any of the libraries that were mentioned in this thread.

Maybe I was too curt?

My point was that if we want people to contribute to our libraries in 2024, we shouldn't require from them to do so using C++98 code[...]

And we don't. We only require that "A library runs on at least two C++ compilers implementing the latest ISO C++ standard." (https://www.boost.org/development/requirements.html#Portability) There's also no requirement that new libraries use specific Boost libraries as a dependency, although reasonable code reuse is encouraged. (https://www.boost.org/development/reuse.html) The mere presence of the older libraries in the list is not a requirement to use them.

I'd like to add to this part that contributors to existing libraries may be asked to support specific C++ versions, which the library maintainers have chosen to support. I think, this arrangement is fair and should remain.

...

I'm not young, but I would certainly prefer to write C++11 than C++98.

Me too, and I share that preference, but this has nothing to do with library marking or forcing them on users.

...

...

If anything, declaring core libraries deprecated would force downstream users to seek for alternatives and update their code.

The suggestion here wasn't about declaring core libraries deprecated... well, it was, but "obsolete" is a better term than "deprecated". It's about discouraging the use of obsolete libraries in new code. The problem is that when we display the list of libraries, we give no hints to the initiated that a library has been obsoleted by the language (which is the case with Move and Foreach), the stdlib (the case with Bind, MemFn, Ratio, and many others), or by another Boost library (MPL and Mp11.)

Without further clarification, I don't see much difference between marking libraries "deprecated" or "obsolete".

Again, as a library user, I'm most interested in two things about the library: whether it is working, and whether it may potentially become unavailable (with varying degrees and ways of "unavailable"). Marking the library as "deprecated" or "obsolete" gives me a strong impression that it may be removed and it should not be used - whether in new or existing (but still maintained) code.

And yes, I see no real difference between new and existing code in the context of using obsolete/deprecated dependencies. As long as I want to keep a piece of code working, I would have to avoid using obsolete/deprecated APIs in it, regardless of how new it is.

...

Yes, this actually happens; people do sometimes choose to use an obsolete library in error just because our list doesn't make the above clearer.

Which is why I suggested to add more expanded notices to library docs, suggesting more modern alternatives where possible.

Andrey Semashev wrote:

On 10/8/24 03:31, Peter Dimov via Boost wrote:

...

My point was that if we want people to contribute to our libraries in 2024, we shouldn't require from them to do so using C++98 code[...]

And we don't. We only require that "A library runs on at least two C++ compilers implementing the latest ISO C++ standard." (https://www.boost.org/development/requirements.html#Portability) There's also no requirement that new libraries use specific Boost libraries as a dependency, although reasonable code reuse is encouraged.

It's not about new libraries, but contributions/PRs to existing libraries. This is a separate topic that is unrelated to our marking libraries as obsolete; it was a response to the previously raised "why would anyone want to upgrade an existing working C++03 library to C++11 or later."

Le lun. 7 oct. 2024 à 01:50, Brook Milligan via Boost a écrit :

...

On Oct 6, 2024, at 1:13 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

I would think that serialization should be added to this list as it uses a lot of "deprecated" libraries and this is not going to change.

...

I would expect that the serialization library is used for possibly long-term archives and so stability would be super important.

...

If so, it should not be deprecated, which might suggest that whatever it depends should not be either. Perhaps this needs more > thought?

Sorry for the delay. This is the case in our production code. We heavily

use Boost.Serialization and since back 2004. We have hundreds of systems in use by our customers. So, this library must be considered with a lot of attention. Best regards, Marc Viala

Hi, I think its a great idea. Den fre 11 okt. 2024 15:01Janek Kozicki via Boost skrev:

Marc Viala via Boost said: (by the date of Fri, 11 Oct 2024 07:21:29 +0200)

...

Le lun. 7 oct. 2024 à 01:50, Brook Milligan via Boost < boost@lists.boost.org> a écrit :

...

...

On Oct 6, 2024, at 1:13 PM, Robert Ramey via Boost < boost@lists.boost.org> wrote:

I would think that serialization should be added to this list as it

uses

...

...

a lot of "deprecated" libraries and this is not going to change.

...

I would expect that the serialization library is used for possibly long-term archives and so stability would be super important.

...

If so, it should not be deprecated, which might suggest that whatever it depends should not be either. Perhaps this needs more > thought?

Sorry for the delay. This is the case in our production code. We heavily use Boost.Serialization and since back 2004. We have hundreds of systems in use by our customers. So, this library must be considered with a lot of attention.

Best regards, Marc Viala

I agree that serialization is an extremely useful library. I use it in almost all of my projects, and for example YADE software, which I co-founded 20 years ago, is very widely used by the universities around the world. Removing serialization library would be a very major blow.

best regards Janek Kozicki

-- Janek Kozicki, PhD. DSc. Arch. Assoc. Prof. Gdansk University of Technology (Gdansk Tech) Faculty of Applied Physics and Mathematics Institute of Physics and Applied Computer Science Division of Theoretical Physics and Quantum Information -- http://yade-dem.org/ http://pg.edu.pl/p/jan-kozicki-19725 http://mostwiedzy.pl/en/jan-kozicki,19725-1 ORCID: https://orcid.org/0000-0002-8427-7263

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

On 10/7/24 6:15 AM, Rainer Deyke via Boost wrote:

I approve of a hypothetical Boost 2.x without the obsolete libraries that can be used alongside Boost 1.x.

approve of Boost 2.x using C++ modules from the beginning.

Good luck with that.

I approve of Boost 1.x continuing to get new releases, but gradually being replaced by Boost 2.x in new code.

I'm skeptical that one will be able to mix boost 2.x and boost 1.x and still maintain some sort of coherence. I'll just wait and see. So phrasing my original question in terms of the above: Boost serialization library should be marked obsolete? Note that I'm not advocating in favor or against this proposition. I'm just trying to understand it. And any library which uses an "obsolete" library would also be "obsolete". Have I got this right? Robert Ramey

On 10/7/24 18:19, Robert Ramey via Boost wrote:

And any library which uses an "obsolete" library would also be "obsolete".

Have I got this right?

I hope not. If a library uses an obsolete library in its API, then it should consider providing an alternative API using newer alternatives alongside the old API. If a library uses an obsolete library as an implementation detail, then it's not harming anybody. The library can switch to a more modern implementation when and if this is convenient. -- Rainer Deyke - rainerd@eldwood.com

René Ferdinand Rivera Morell wrote:

On Fri, Oct 4, 2024 at 1:21 PM Vinnie Falco via Boost wrote:

...

Should one or more of these libraries be marked as "deprecated" in their corresponding meta/libraries.json?

Posting this at the top of the thread for visibility.. Maybe the problem everyone is having in the "deprecated" term. It seems we are more looking to mark libraries as "obsolete". So perhaps adding such a new field with a value that lists the not-obsolete equivalent libraries and displaying that on the web site would be more useful. That way users know the status and have a clear place to look instead.

+1