Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125374
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Subject: Re: [PHP-DEV] PHP 8.3.11 Released
In-Reply-To: <261c47a3-f3d7-4328-9cb9-1b9a44e0fb5b@gmx.de>
Date: Sun, 1 Sep 2024 03:16:58 -0400
Cc: Derick Rethans <derick@php.net>,
 PHP internals <internals@lists.php.net>,
 Jakub Zelenka <bukka@php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <621B5876-919D-4C97-B0B3-0E5A658F8EA7@newclarity.net>
References: <CAEKnhAEtioYxpYO9byRr4-ygoP0O9ig5rxYnwCVGc2RKs2grJQ@mail.gmail.com>
 <9b35954d-ae70-4c74-ab85-2ecacfd594fb@gmx.de>
 <CAEKnhAHVrLC0BHNq74g1YCo=M9AhXZfghdWJ=zY2WYpGsDXQSw@mail.gmail.com>
 <594b4499-7919-496d-a039-1c1afa06b8a1@gmx.de>
 <2E5F4DF6-CCE0-43BB-9F1B-5E82FFB89EBB@php.net>
 <261c47a3-f3d7-4328-9cb9-1b9a44e0fb5b@gmx.de>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
From: mike@newclarity.net (Mike Schinkel)

> On Aug 31, 2024, at 1:44 PM, Christoph M. Becker <cmbecker69@gmx.de> =
wrote:
>=20
> On 31.08.2024 at 19:35, Derick Rethans wrote:
>=20
>> Shouldn't we have bumped the API number for this? Better safe than =
sorry.
>=20
> 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).
>=20
>> 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.
>=20
> 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. =20

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.=20

Something to consider.

-Mike=