The PHP development team announces the immediate availability of PHP
8.3.11. This is a bugfix release.
All PHP 8.3 users are encouraged to upgrade to this version.
For source downloads of PHP 8.3.11 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at
https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8
Many thanks to all the contributors and supporters!
Jakub Zelenka, Eric Mann and Pierrick Charron
Release Manifest here and below:
https://gist.github.com/bukka/e5a6efda83de60fbd217ea1ce64cb376
php-8.3.11.tar.bz2
SHA256 hash:
6640e2455080a89adc41d4e57bb04f8c2bfb7eec627fe199af973bff34d7f0ee
PGP signature:
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZs4m5gAKCRAcB3ncXAqd
5JaSAP9uBHQsLxc9nmG0RBgvgdDInZm4OH47ZmLtpjW6SUSUegD/QZqZkUVwuM/A
knc0pqx0+5ZQmrWsimpWIf9hw4w2GQM=
=MEJc
-----END PGP SIGNATURE-----
php-8.3.11.tar.gz
SHA256 hash:
b93a69af83a1302543789408194bd1ae9829e116e784d578778200f20f1b72d4
PGP signature:
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZs4m5wAKCRAcB3ncXAqd
5N/vAP90ZOHyk1ZhFpsQkTh89s1AIRhL7shHX/NBT5KRtA91TgD/S9/EpPfplJXZ
nKsk5A6vN1agTuX7UQ/Qj4n8Yn61BAs=
=WfaD
-----END PGP SIGNATURE-----
php-8.3.11.tar.xz
SHA256 hash:
b862b098a08ab9bf4b36ed12c7d0d9f65353656b36fb0e3c5344093aceb35802
PGP signature:
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTCjZN1dWA+tKu3JYYcB3ncXAqd5AUCZs4m5wAKCRAcB3ncXAqd
5GEcAQDijVOhXPZKRA3CPaut9JwOysoNgX9/A5zLeMGgTwUMIwEAwGig+o0XKonL
Ay0PrGtv7SLU3ZUXKGIfo/E2jCDlUgE=
=1Ytt
-----END PGP SIGNATURE
The PHP development team announces the immediate availability of PHP
8.3.11. This is a bugfix release.All PHP 8.3 users are encouraged to upgrade to this version.
For source downloads of PHP 8.3.11 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at
https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8
Shouldn't there be an explicit announcement regarding the revert of the
fix for GH-14930? Most notably the information that extensions having
been built against PHP 8.3.10 may need to be rebuilt. That may affect
some distros, but also custom builds.
Christoph
On Fri, Aug 30, 2024 at 2:59 PM Christoph M. Becker cmbecker69@gmx.de
wrote:
The PHP development team announces the immediate availability of PHP
8.3.11. This is a bugfix release.All PHP 8.3 users are encouraged to upgrade to this version.
For source downloads of PHP 8.3.11 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at
https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8Shouldn't there be an explicit announcement regarding the revert of the
fix for GH-14930? Most notably the information that extensions having
been built against PHP 8.3.10 may need to be rebuilt. That may affect
some distros, but also custom builds.
There is a note in NEWS about the revert. I'm not sure if we usually do any
separate announcement for those kind of things. I don't remember any such
announcement but might be a good idea. Although it is really just for
packagers so not sure if php.net is the right place. Maybe just having this
discussion here might be enough.
Regards
Jakub
On Fri, Aug 30, 2024 at 2:59 PM Christoph M. Becker cmbecker69@gmx.de
wrote:There is a note in NEWS about the revert. I'm not sure if we usually do any
separate announcement for those kind of things. I don't remember any such
announcement but might be a good idea. Although it is really just for
packagers so not sure if php.net is the right place. Maybe just having this
discussion here might be enough.
Maybe. :) On the other hand, it shouldn't hurt to amend the release
announcement on php.net with something like the following:
PHP 8.3.10 introduced an ABI break in the streams layer, which has been
reverted in PHP 8.3.11. That means that extensions using the streams
layer which have been built for PHP 8.3.10 must not be used with other
PHP 8.3 versions, and vice versa, that such extensions built for other
PHP 8.3 versions must not be used with PHP 8.3.10.
And maybe note that Windows (and perhaps some other platforms) are not
affected by this.
Christoph
On Fri, Aug 30, 2024 at 2:59 PM Christoph M. Becker cmbecker69@gmx.de
wrote:There is a note in NEWS about the revert. I'm not sure if we usually do any
separate announcement for those kind of things. I don't remember any such
announcement but might be a good idea. Although it is really just for
packagers so not sure if php.net is the right place. Maybe just having this
discussion here might be enough.Maybe. :) On the other hand, it shouldn't hurt to amend the release
announcement on php.net with something like the following:PHP 8.3.10 introduced an ABI break in the streams layer, which has been
reverted in PHP 8.3.11. That means that extensions using the streams
layer which have been built for PHP 8.3.10 must not be used with other
PHP 8.3 versions, and vice versa, that such extensions built for other
PHP 8.3 versions must not be used with PHP 8.3.10.And maybe note that Windows (and perhaps some other platforms) are not
affected by this.Christoph
Shouldn't we have bumped the API number for this? Better safe than sorry.
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.
cheers
Derick
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.
Christoph
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
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.
We already have the "problem" that we tag on Tuesdays, but release on
Thursdays, but you find builds from Wednesdays in Linux distros.
Christoph
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:
- Revert the code.
- Calculate a new tag by incrementing the to-be-reverted tag by 0.0.1
- Commit the changes with a commit message saying the commit reverts the prior commit named by the new tag.
- Tag the changes with the new tag and a message saying it reverts the prior patch tag.
- 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