On Sat, Oct 5, 2024 at 1:20 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
What would be the meaning of such markup?
Yes, great question. The internal flag may be called "deprecated," and we have the freedom to display this to the user any way that we want. Perhaps the UI will say "obsolete" or "superceded by ___." Do you have a preference or suggestion for presentation?
When we mark some parts of library API as deprecated we intend to eventually remove it. Are you proposing to remove these libraries after the deprecation period?
I'm only proposing to have a conversation. I have not looked closely at these libraries to know whether removing them is practical or harmless.
What would you recommend to do to users of these libraries, both within and outside Boost? Note that in some cases it isn't possible to port from these libraries without also breaking user-visible API in downstream libraries. So removing those libraries will have implications beyond their direct users.
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. Thanks