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.