On 07/07/2025 15:40, Artyom Beilis via Boost wrote:
On Mon, Jul 7, 2025 at 4:00 PM Daniele Lupo via Boost <boost@lists.boost.org> wrote:
On 07/07/2025 14:45, Artyom Beilis via Boost wrote: I've said this many times. This should not be an issue. Every library at some point breaks with the past and go ahead, for many reason, maintanance, readability etc... And for that reason we also have the X.Y.Z version numbering where
True but Boost have never followed this. The major version = 1.XX and rest are never handled.
What would be the correct solution is something like Boost.LTS 2.
That would carry API and ABI stable for years to come and release minor updates and anything that breaks goes to next version till it is released after YEARS not few months.
And the rest of the updates are backward API/ABI compatible.
ABI compatibility is a delicate matter. Yes, I agree that for some long-term project it can be helpful, but it can also limit the development of libraries a lot. We all know about std::regex and its limits due to the fact that it needs to maintain ABI compatibility. It's a tradeoff between stability and agility in implementing new features (or simply fixing bugs); maintaing ABI compatibility make those process far more complicated, and I'm personally against things lime PIMPL like Qt does, but remember, it's my personal opinion, it does not count in a community decision. My feeling is that in Boost API are more important that ABI; if you download the new version of boost is because you want to use it in your project, and since many boost libraries are header-only, in order to use boost you need to rebuild the project. Sure, you can link your project to another legacy one that cannot be recompiled, but in that case you can stay with your current version of Boost, or the boost community can ensure that X.Y.Z version of boost libraries maintains the same ABI for every patch version (X, Y remains the same, Z is updated). It's possible to maintain a rule that say - Patch version update: ABI compatibility guaranteed - Minor version update: API compatibility guaranteed - Major version update: Some API is broken (you can need to change your code) As I've said before, I'm not a huge fan of ABI compatibility, probably because it's not important in my work, but if it's important for many developers we can decide something like that. Anyway I think that about it Boost community should make some discussion and decision, then take the decision and use them for create the Boost 2.0, where those decisions became the guidelines for developing of new libraries.