Re: Technical Excellence?

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2024-03-30 13:10:57

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_at_[hidden])