> On Aug 31, 2024, at 1:44 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote: > > On 31.08.2024 at 19:35, Derick Rethans wrote: > >> Shouldn't we have bumped the API number for this? Better safe than sorry. > > That ABI break was accidentially committed. There was some discussion > whether to stick with the break and bump API numbers, or to revert, and > there was consensus that in this case the latter makes more sense (after > all, just a single release was affected, and only relevant for > extensions which actually use the streams layer). > >> And I'm wondering why we have no tests for ABI breaks here? I'm sure that I >> have seen a report (from Remi?) that highlighted these breakages when I was >> still involved in the mongodb extension. > > There was the idea to do some verifcation, but maybe it's enough to add > something to the PR-labeler which just labels any PR which modifies a > public header.
One of the benefits for users when software authors strictly follow SemVer is that automated tooling can decide if an automatic upgrade should be safe. Depending on out-of-band information to convey BC breakage can result in those who use automatic upgrades to see unexpected failures en masse since automated tooling won't look at bespoke, non-standard labels when deciding. If enough software authors choose to be less strict about SemVer it could have the fallout that many people decide it is just too risky to use automated tooling. Once bitten, twice shy. One approach I have seen on other projects take is they retract the versions with BC breakage and then release an update reversing the breakage. Something to consider. -Mike
