On 27.03.24 18:04, Daniele Lupo via Boost wrote:
On 27/03/2024 17:47, Andrey Semashev via Boost wrote:
The biggest obstacle to removing any library is that the library may have users. This is true regardless of the perceived quality or "modern-ness" of the library.
If boost remains stuck with this, no libraries will ever be removed.
In my opinion at some point it's necessary to say clear and loud "this library will be deprecated in Boost 1.87.0 and removed in 1.90.0". Users that will use the library will have time to update their code, and if it's some legacy code that cannot be removed, simply they will not update boost anymore in their environment, remaining stuck to the last version that they will use and that support that library. It's always possible, if necessary, to give a patch release for that version if necessary. For example if boost is updated to 1.95.0, and we discover a severe bug, it's always possible to release a 1.89.1 release, that is the last release that support the removed library. But only if needed. It should be also possible to define the last supported version, saying that bugs in version that are newer that this one will be patched if needed like I've said, otherwise the version is out of support.
For example, for smart pointers (I don't say that we need to remove it, it's only an example) we can write in the site and in the documentation
- this library is deprecated since version 1.87.0 - this library will be removed in version 1.91.0
And also
- The oldest version of Boost actively supported is the 1.84.0 (that means that it's possible to have 1.84.1, but not 1.83.1).
This way it's possible to:
- Remove old libraries (i.e. smart pointers, since they are supported in C++11) - Give time to people that use deprecated libraries to update their code - Support people that cannot update the code for any reason for a defined period of time.
I strongly feel that certain old libraries should be deprecated. I also strongly feel that these libraries should never be removed - or at least, not without a Boost 2.0 release in a boost2 namespace that can exist side by side with Boost 1.x. Deprecation should means that there is broad agreement that the library should not be used in new code. One corollary to that is that new code should have better alternatives available. Forcing people to pin their legacy code to old versions of Boost goes directly against that goal. Example: library X2 is introduced to Boost as a better replacement to library X1, and library X1 is deprecated. I have a project that uses X1. Refactoring existing code to use X2 is not viable, so the project is pinned to the latest version of Boost that still includes X1. Then X3 is introduced and X2 is deprecated, but I am forced to continue using X2 because my project is pinned to a version of Boost that does not include X3. -- Rainer Deyke (rainerd@eldwood.com)