Re: Technical Excellence?

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-04-02 11:20:53

On 4/2/24 13:46, Daniele Lupo via Boost wrote:
> 
>> And kill projects that target older C++03 platforms?
>> Don't maintain, update or improve, but remove?
>>
>> If somebody wants some smart pointer that is consistent across
>> compiler versions that boost ones are a very good case.
>>
>> Be responsible to ones who use your code. Don't break it unless
>> it is absolutely necessary
> 
> In my opinion, yes.
> 
> Let's start from a point: nobody wil kill C++03 code on older platforms
> and with older compilers: it will continue to work properly with
> existing boost versions. Simply, the old code will not be able to use,
> at some point, the latest boost version, and that's also ok,

No, not ok.

Incompatibility with newer Boost releases means that the code is no
longer compatible with other code that *requires* the newer Boost. For
example, a library that uses boost::shared_ptr will be incompatible with
an application or another library that requires Boost version where
boost::shared_ptr has been removed.

There is also an issue of shipping the code that requires an older Boost
version in a Linux distro (and probably other OS distros), because
typically distros only ship one Boost version system-wide. This means
that either distro maintainers now have to ship multiple Boost versions
(which is a maintenance and technical problem) or the code in question
needs to be removed from distro and manually built by users who need it
(which is, again, a maintenance and technical problem shifted downstream).

Note that building old Boost on a newer system may be problematic by
itself due to updated dependencies. For example, if the old Boost was
only compatible with OpenSSL 1.0 and the newer system has migrated to
OpenSSL 3.0, you won't be able to build without extensive patching.

(By "technical problem" above I mean that two different Boost versions
may not be possible to install on the same system using the standard
package manager. Yes, shared libraries can coexist via version suffixes
in library names, but this doesn't work for headers and static
libraries. Fixing this would require renaming libraries and header
directories and would break builds of everything downstream, so
basically won't happen.)

> My idea, as I've said, is to deprecate old libraries at some point,
> remove them later in a future version, and maintain old boost version
> for bugfixing.

That's also problematic. The current Boost workflow is not well suited
for maintenance releases, let alone maintenance of older branches of
Boost. There are no older branches. Every Boost release is made from
master, and represents its current state, with all bug fixes, new
features and removals, should those happen.

Then there is the added maintenance burden of the older branches, if we
were to create them.

So there's another problem to the "old code uses old Boost" approach: we
don't do point releases. I'm going to leave the discussion on whether
this is good or bad aside, but this means if there's a bug or security
vulnerability in the older Boost version, the old code is either stuck
with it or has to patch their Boost themselves.

So my main point is that "old code uses old Boost" is a myth in practice.