On Monday, July 7, 2025 3:40 PM, Jakob Lövhall wrote:
It is more like a fence, or wall, blocking improvement imho.
It doesn't block all improvements, nor would I envision a scenario where strict ABI compatibility is required over an extended range of releases. I merely suggested that ABI-breaking changes might be managed in some way, rather than being completely ad hoc. One way they could be managed is with versioned namespaces. Another way would be to adhere to proper semantic versioning and then space out the releases with ABI and API -breakage a little more.
Sure sometimes libraries are built with a earlier version that one would like. It sucks to be on that earlier version when its known that there is some dope feature in a newer version.
I think we're mostly saying the same thing, here. If ABI-incompatible versions of Boost were fewer and farther in between, then you could usually upgrade to a newer version of Boost and utilize some newer features, even when linking against some 3rd libraries that also use Boost. They wouldn't hold you back so strictly, like they do today.
at some point in the future, dependencies could update and you get improvements.
Distros try to avoid incompatible library dependency changes, [i]precisely because[/i] they can ripple through library dependency chains like a bunch of dominos. The exceptions are when you're on a rolling-release distro or you perform a wholesale upgrade of a stable distro.
With ABI stability you could upgrade right away (if the issue is specifically dynamic linkage to targets with non hidden symbols), but pay the cost of not having the same improvements.
Right. You'd be limited in the nature and extent of improvements you could attain, without jumping to a new major version. I do wonder how often ABI-incompatible changes are really necessary. There's also an uncounted benefit, which is the potential for more libraries (esp. open source) to use Boost, if some of the current downsides of doing so were mitigated. Unfortunately, I think that ship has pretty much sailed. Matt -----Original Message----- From: Jakob Lövhall <lovhall@protonmail.com> Sent: Monday, July 7, 2025 3:40 PM To: Boost developers' mailing list <boost@lists.boost.org> Cc: Matt Gruenke <mgruenke@tycoint.com> Subject: Re: [boost] Re: API Stability (was: A proposal for a modern build-system_
Just out of curiosity: are you developing on Windows or Linux?
Linux
ABI compatibility is indeed a high bar, It is more like a fence, or wall, blocking improvement imho.
Sure sometimes libraries are built with a earlier version that one would like. It sucks to be on that earlier version when its known that there is some dope feature in a newer version. But, then sure, be stuck on that earlier version. Then you get all the functionality from that version, but on the other hand, at some point in the future, dependencies could update and you get improvements. With ABI stability you could upgrade right away (if the issue is specifically dynamic linkage to targets with non hidden symbols), but pay the cost of not having the same improvements. Jakob