Hi
Am 2026-04-27 20:09, schrieb Eric Norris:
Personally, given that both of these versions are EOL, this feels
acceptable, but I'm curious what others think.
I agree that it is a reasonable expectation from users to use the latest (or at least: a supported) version of third party software when they want to use the latest PHP version. Especially since my understanding is that in this instance, the communication would also not be broken entirely, but users would just need to disable persistent connections, no? This means if they want to upgrade PHP, without being able to upgrade their MySQL version they would potentially need to give up some performance optimization, but other than that it would work unchanged?
Somewhat relatedly, see: Require Autoconf 2.71 or newer by petk · Pull Request #21159 · php/php-src · GitHub. I think it would be good to decide both cases at the same time, since they are reasonably similar.
Best regards
Tim Düsterhus
On Thu, Apr 30, 2026 at 3:49 AM Tim Düsterhus <tim@bastelstu.be> wrote:
Hi
Am 2026-04-27 20:09, schrieb Eric Norris:
> Personally, given that both of these versions are EOL, this feels
> acceptable, but I'm curious what others think.
I agree that it is a reasonable expectation from users to use the latest
(or at least: a supported) version of third party software when they
want to use the latest PHP version. Especially since my understanding is
that in this instance, the communication would also not be broken
entirely, but users would just need to disable persistent connections,
no? This means if they want to upgrade PHP, without being able to
upgrade their MySQL version they would potentially need to give up some
performance optimization, but other than that it would work unchanged?
That's a great point, and correct - users can still upgrade, they just
will need to give up persistent connections.
Somewhat relatedly, see:
Require Autoconf 2.71 or newer by petk · Pull Request #21159 · php/php-src · GitHub. I
think it would be good to decide both cases at the same time, since they
are reasonably similar.
That could make sense, and how would you suggest we proceed to decide
the case? I'll admit that I'd be hesitant to need to resolve that via
an RFC, since if the RFC failed I'd need to potentially make another
RFC just for my change + some INI setting, and so it'd be quite some
time until I could get this merged. That's not to say we shouldn't do
it, I'm just noting my hesitation.
Hi
Am 2026-04-30 16:11, schrieb Eric Norris:
Somewhat relatedly, see:
Require Autoconf 2.71 or newer by petk · Pull Request #21159 · php/php-src · GitHub. I
think it would be good to decide both cases at the same time, since they
are reasonably similar.
That could make sense, and how would you suggest we proceed to decide
the case? I'll admit that I'd be hesitant to need to resolve that via
an RFC, since if the RFC failed I'd need to potentially make another
RFC just for my change + some INI setting, and so it'd be quite some
time until I could get this merged. That's not to say we shouldn't do
it, I'm just noting my hesitation.
A single RFC with two primary votes to independently resolve each of the two cases (at the same time) would work. Given the concerns and the similarity between both, I don't think we can do without an RFC.
Best regards
Tim Düsterhus
On Sun, May 3, 2026 at 8:01 AM Tim Düsterhus <tim@bastelstu.be> wrote:
A single RFC with two primary votes to independently resolve each of the
two cases (at the same time) would work. Given the concerns and the
similarity between both, I don't think we can do without an RFC.
Fair enough. I'd appreciate your collaboration on this RFC if you're
amenable! I've started a draft here:
PHP: rfc:min_supported_versions_php_8_6.
I have a few things to note:
- I wasn't sure how to approach the merger of the two topics. I
decided to model this like the various deprecation RFCs, in that we're
deciding on a slate of minimum supported software for PHP 8.6.
- Ideally, if people objected to the MySQL minimum version for
persistent connections, I'd be able to include a vote that allowed for
an INI setting.
- Related to that: I'm not sure how much detail to add about the
actual implementation I'd like for persistent connections. Is this a
vote for my specific implementation, or just the higher-level concept
of requiring a certain version of software in PHP 8.6? My goal is to
ship this, so needing to do two RFCs back-to-back would be annoying.
Feel free to respond privately if you'd like to take this off-list. Thanks!
Hi
Am 2026-05-03 16:14, schrieb Eric Norris:
- I wasn't sure how to approach the merger of the two topics. I
decided to model this like the various deprecation RFCs, in that we're
deciding on a slate of minimum supported software for PHP 8.6.
Yes, that makes sense to me.
- Ideally, if people objected to the MySQL minimum version for
persistent connections, I'd be able to include a vote that allowed for
an INI setting.
This would effectively be two competing RFCs and that could work with our voting policy. One possible issue is that folks might be biased against voting for the upgrade if there is the INI escape hatch. I really don't like the extra maintenance effort (e.g. duplicate code paths that no one is going to test) of the INI. I generally think an opinionated RFC by a subject matter expert (i.e. you :-)) is stronger than one that leaves every decision up to the voters.
- Related to that: I'm not sure how much detail to add about the
actual implementation I'd like for persistent connections. Is this a
vote for my specific implementation, or just the higher-level concept
of requiring a certain version of software in PHP 8.6? My goal is to
ship this, so needing to do two RFCs back-to-back would be annoying.
IMO it should be a vote for the increased minimum version with a good argument as to why this increased minimum version is useful, specifically “more predictable behavior for persistent connections, because any per-connection state can cleanly be reset” and “support for C11 in autotools, which already is the documented minimum in php-src/CODING_STANDARDS.md at 8d0777e88b8494807727fc57c148c2497976eff5 · php/php-src · GitHub, but folks will only notice if compilation fails halfway through”.
Best regards
Tim Düsterhus
This would effectively be two competing RFCs and that could work with
our voting policy. One possible issue is that folks might be biased
against voting for the upgrade if there is the INI escape hatch. I
really don't like the extra maintenance effort (e.g. duplicate code
paths that no one is going to test) of the INI. I generally think an
opinionated RFC by a subject matter expert (i.e. you :-)) is stronger
than one that leaves every decision up to the voters.
Fair enough! I'll see where the discussion goes and use that to inform
my decision, but stick with a single vote for now.
IMO it should be a vote for the increased minimum version with a good
argument as to why this increased minimum version is useful,
specifically “more predictable behavior for persistent connections,
because any per-connection state can cleanly be reset” and “support for
C11 in autotools, which already is the documented minimum in
php-src/CODING_STANDARDS.md at 8d0777e88b8494807727fc57c148c2497976eff5 · php/php-src · GitHub,
but folks will only notice if compilation fails halfway through”.
That makes sense to me. That said, I don't personally have anything
more to say about the autoconf change, other than "it sounds like a
good idea." I will need you or someone (Peter Kokot?) who is more
knowledgeable about autoconf and the build system to write that
section if we're going to make this a combined RFC.
Hi
Apologies for the late reply. It's been a busy May for me with conferences and other important day job duties.
Am 2026-05-08 14:54, schrieb Eric Norris:
IMO it should be a vote for the increased minimum version with a good
argument as to why this increased minimum version is useful,
specifically “more predictable behavior for persistent connections,
because any per-connection state can cleanly be reset” and “support for
C11 in autotools, which already is the documented minimum in
php-src/CODING_STANDARDS.md at 8d0777e88b8494807727fc57c148c2497976eff5 · php/php-src · GitHub,
but folks will only notice if compilation fails halfway through”.
That makes sense to me. That said, I don't personally have anything
more to say about the autoconf change, other than "it sounds like a
good idea." I will need you or someone (Peter Kokot?) who is more
knowledgeable about autoconf and the build system to write that
section if we're going to make this a combined RFC.
Something like this should hopefully work:
The officially documented minimum version of the C standard that is supported by PHP is [C11 as of PHP 8.4]([skip ci] Bump required C standard to C11 · php/php-src@631bab4 · GitHub). This requirement is however not explicitly checked in a programmatic fashion, which means that users trying to build PHP with an older compiler that does not support the C11 standard might encounter non-obvious build failures. The currently used minimum version of autoconf, which is the tool used to generate the ./configure script which is used for feature detection, is 2.68 and does not yet know about C11, preventing it from reliably detecting the minimum requirement and associated features.
We propose increasing the minimum version of autoconf 2.71 from 2.69. The updated version has official support for C11 and also allows to simplify some of the existing autoconf definitions, simplifying maintenance for the PHP Core team.
autoconf is only required when building from git. The official PHP release tarballs contain a pre-generated ./configure script that is generated by the release managers, thus this change does not affect users that build from the official releases. For users that build from git, autoconf 2.71 was released in January 2021 and is available by default in the current stable versions for all common Linux distributions. This includes Debian 12+ (Bookworm), Ubuntu 22.04+ (jammy), RHEL 10, Fedora 38+, Alpine Linux 3.16+, OpenSuse Leap 16.
Best regards
Tim Düsterhus
On Tue, Jun 2, 2026 at 9:26 AM Tim Düsterhus <tim@bastelstu.be> wrote:
Hi
Apologies for the late reply. It's been a busy May for me with
conferences and other important day job duties.
Am 2026-05-08 14:54, schrieb Eric Norris:
>> IMO it should be a vote for the increased minimum version with a good
>> argument as to why this increased minimum version is useful,
>> specifically “more predictable behavior for persistent connections,
>> because any per-connection state can cleanly be reset” and “support
>> for
>> C11 in autotools, which already is the documented minimum in
>> php-src/CODING_STANDARDS.md at 8d0777e88b8494807727fc57c148c2497976eff5 · php/php-src · GitHub,
>> but folks will only notice if compilation fails halfway through”.
>
> That makes sense to me. That said, I don't personally have anything
> more to say about the autoconf change, other than "it sounds like a
> good idea." I will need you or someone (Peter Kokot?) who is more
> knowledgeable about autoconf and the build system to write that
> section if we're going to make this a combined RFC.
Something like this should hopefully work:
> The officially documented minimum version of the C standard that is
> supported by PHP is [C11 as of PHP
> 8.4]([skip ci] Bump required C standard to C11 · php/php-src@631bab4 · GitHub).
> This requirement is however not explicitly checked in a programmatic
> fashion, which means that users trying to build PHP with an older
> compiler that does not support the C11 standard might encounter
> non-obvious build failures. The currently used minimum version of
> autoconf, which is the tool used to generate the ./configure script
> which is used for feature detection, is 2.68 and does not yet know
> about C11, preventing it from reliably detecting the minimum
> requirement and associated features.
>
> We propose increasing the minimum version of autoconf 2.71 from 2.69.
> The updated version has official support for C11 and also allows to
> simplify some of the existing autoconf definitions, simplifying
> maintenance for the PHP Core team.
>
> autoconf is only required when building from git. The official PHP
> release tarballs contain a pre-generated ./configure script that is
> generated by the release managers, thus this change does not affect
> users that build from the official releases. For users that build from
> git, autoconf 2.71 was released in January 2021 and is available by
> default in the current stable versions for all common Linux
> distributions. This includes Debian 12+ (Bookworm), Ubuntu 22.04+
> (jammy), RHEL 10, Fedora 38+, Alpine Linux 3.16+, OpenSuse Leap 16.
Best regards
Tim Düsterhus
Thank you, I've added that verbatim to the RFC draft and published it
for discussion.