> On Sep 1, 2024, at 6:12 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote: > > On 01.09.2024 at 09:16, Mike Schinkel wrote: > >> 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. > > What does "retract" mean in this context? I mean, we can delete the > tag, remove the download from php.net – 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. 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. 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
