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.