Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125385
Content-Type: text/plain;
	charset=utf-8
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: <a621ab6e-9591-4353-ba53-11a8c84d62da@gmx.de>
Date: Mon, 2 Sep 2024 08:58:40 -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: <0A6AB07F-848E-4A3C-AE18-E0384D9A7C2E@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>
 <621B5876-919D-4C97-B0B3-0E5A658F8EA7@newclarity.net>
 <a621ab6e-9591-4353-ba53-11a8c84d62da@gmx.de>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
From: mike@newclarity.net (Mike Schinkel)

> On Sep 1, 2024, at 6:12 PM, Christoph M. Becker <cmbecker69@gmx.de> =
wrote:
>=20
> On 01.09.2024 at 09:16, Mike Schinkel wrote:
>=20
>> 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.
>>=20
>> 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
> What does "retract" mean in this context?  I mean, we can delete the
> tag, remove the download from php.net =E2=80=93 but the version has =
already been
> released, and might be used in the wild.

Retraction is something I know from Go, but after your question I =
learned that it may be a concept Go introduced as go's binary has =
tooling to detect and warn against reversions built-in. =20

If you are unfamiliar with Go, it has location of downloadable source as =
a first class concept in the package name, hence =
`example.com/my/package` can be downloaded with `go get =
example.com/my/package`.  If I had published then retracted a version =
1.5.0 and you were to `go get example.com/my/package@1.5.0` then Go =
would warn you that the package is retracted.

Still, you do not need any tooling to effectively revert for all intents =
and purposes:

1. Revert the code.
2. Calculate a new tag by incrementing the to-be-reverted tag by 0.0.1
3. Commit the changes with a commit message saying the commit reverts =
the prior commit named by the new tag.
4. Tag the changes with the new tag and a message saying it reverts the =
prior patch tag.
5. Edit the messages of the reverted tag and reverted commit by =
prefixing them "REVERTED:" and "REVERTED IN x.x.x:", respectively.

Here are some links covering reversion in Go if you want to dive deeper =
into their approach:

- https://www.jvt.me/posts/2024/01/15/retract-go-release/
- https://play-with-go.dev/retract-module-versions_go119_en/


> We already have the "problem" that we tag on Tuesdays, but release on
> Thursdays, but you find builds from Wednesdays in Linux distros.

Retracting is never meant to erase history, and we cannot guard against =
all possible use. Retracting is meant to (hopefully greatly) minimize =
the use and any fallout that might otherwise occur. =20

Further, retracting "swims with the current rather than against it" (my =
metaphor) meaning that automated tooling would choose to deploy the =
fixed version over the broken one and would also upgrade from the broken =
one to the fixed one as soon as the tooling was run again.

In the case that a Linux distro captures the reverted release into a =
periodic release of their distro, then whoever discovers this could =
submit a bug fix for them to issue their own bug fig for their released =
version to update to the +0.0.1 tag.

Not perfect, but perfect is usually the enemy of the good.

Hope this helps.

-Mike=