Everything

php

[RFC] [VOTE] Minimum supported versions for PHP 8.6

php.internals

Eric Norris

47 days ago

Hello all,

I'm announcing the start of the vote for the "Minimum supported
versions for PHP 8.6" RFC. The voting will end at 2026-07-30 15:48:00
UTC. There are multiple votes, one for each minimum version
requirement.

RFC: https://wiki.php.net/rfc/min_supported_versions_php_8_6
Discussion: https://news-web.php.net/php.internals/131707

Thanks!
Eric

Alexander Kurilo

46 days ago

On 2026-07-16 17:22, Eric Norris wrote:

> Hello all,
>
> I'm announcing the start of the vote for the "Minimum supported
> versions for PHP 8.6" RFC. The voting will end at 2026-07-30 15:48:00
> UTC. There are multiple votes, one for each minimum version
> requirement.
>
> RFC: https://wiki.php.net/rfc/min_supported_versions_php_8_6
> Discussion: https://news-web.php.net/php.internals/131707
>
> Thanks!
> Eric

I'm sorry to bring this up now (I missed the discussion phase) but is
there a reason to make `COM_RESET_CONNECTION` mandatory? I clearly see
the upside of using it but it's a backward compatibility break that I
find hard to justify:

1. If someone relied on the persistent connection state (for whatever
reason that we might not see as the right technical choices, but still),
the behavior of their application will appear silently broken.

2. If someone still uses an older MariaDB/MySQL, they'll get a
significant performance penalty: their persistent connections will
silently turn to non-persistent. And we're not talking about a
decade-old databases!

If it were made optional, looks like both sides win: whoever interested,
can opt in and stop worrying about mutable connection state, and those
who can't do it because they have to use an older DB have one headache
less: the RFC leaves them with few disappointing alternatives such as to
accept the worse performance or not upgrade PHP.

Please correct me if I misunderstood the behavior you propose.


Cheers,
Alex

Eric Norris

46 days ago

On Thu, Jul 16, 2026 at 3:46 PM Alexander Kurilo <alex@kurilo.me> wrote:

>
> On 2026-07-16 17:22, Eric Norris wrote:
> > Hello all,
> >
> > I'm announcing the start of the vote for the "Minimum supported
> > versions for PHP 8.6" RFC. The voting will end at 2026-07-30 15:48:00
> > UTC. There are multiple votes, one for each minimum version
> > requirement.
> >
> > RFC: https://wiki.php.net/rfc/min_supported_versions_php_8_6
> > Discussion: https://news-web.php.net/php.internals/131707
> >
> > Thanks!
> > Eric
>
> I'm sorry to bring this up now (I missed the discussion phase) but is
> there a reason to make `COM_RESET_CONNECTION` mandatory? I clearly see
> the upside of using it but it's a backward compatibility break that I
> find hard to justify:

That's okay, thanks for taking a look!

>
> 1. If someone relied on the persistent connection state (for whatever
> reason that we might not see as the right technical choices, but still),
> the behavior of their application will appear silently broken.

This is the correct understanding of the behavior I propose, though I
would expect it's incredibly rare that code would rely on the prior
behavior.

> 2. If someone still uses an older MariaDB/MySQL, they'll get a
> significant performance penalty: their persistent connections will
> silently turn to non-persistent. And we're not talking about a
> decade-old databases!

This is also the correct understanding of the behavior I propose. I
don't know if I would say this is a *significant* performance penalty,
however, since it depends on the application. I'll also note that
MySQL 5.7.3 is at least a decade old; it was released on December 3rd,
2013.

> If it were made optional, looks like both sides win: whoever interested,
> can opt in and stop worrying about mutable connection state, and those
> who can't do it because they have to use an older DB have one headache
> less: the RFC leaves them with few disappointing alternatives such as to
> accept the worse performance or not upgrade PHP.

There are many ways we could make this optional:

- We could make an INI setting. I believe this is generally frowned
upon by the internals community.
- We could make it so that if `COM_RESET_CONNECTION` doesn't work, we
use the connection anyway. I think this is dangerous, since it would
mean we are silently allowing the "wrong" behavior.
- We could make some sort of PDO option? I'm less familiar with this,
but then I also worry about the complexity of the change. Again,
arguably this feature is the correct and safe behavior, so I'm wary of
adding unnecessary complexity to account for something that should be
discouraged.

Maybe there's another option I haven't thought of, but given the above
options, I feel confident in the current proposal. I don't think it's
unreasonable to ask users to use a modern database version.

> Please correct me if I misunderstood the behavior you propose.

I believe we're on the same page. Thanks again!

Alexander Kurilo

45 days ago

On 2026-07-16 23:10, Eric Norris wrote:

> On Thu, Jul 16, 2026 at 3:46 PM Alexander Kurilo <alex@kurilo.me> wrote:
>>
>> On 2026-07-16 17:22, Eric Norris wrote:
> This is also the correct understanding of the behavior I propose. I
> don't know if I would say this is a *significant* performance penalty,
> however, since it depends on the application. I'll also note that
> MySQL 5.7.3 is at least a decade old; it was released on December 3rd,
> 2013.

Yep, my bad. 2017 and 2013, where MariaDB 10.2 and MySQL 5.7.3 were
release respectively didn't feel that long ago when I was writing the
response :D

>> If it were made optional, looks like both sides win: whoever interested,
>> can opt in and stop worrying about mutable connection state, and those
>> who can't do it because they have to use an older DB have one headache
>> less: the RFC leaves them with few disappointing alternatives such as to
>> accept the worse performance or not upgrade PHP.
>
> There are many ways we could make this optional:
>
> - We could make an INI setting. I believe this is generally frowned
> upon by the internals community.
> - We could make it so that if `COM_RESET_CONNECTION` doesn't work, we
> use the connection anyway. I think this is dangerous, since it would
> mean we are silently allowing the "wrong" behavior.
> - We could make some sort of PDO option? I'm less familiar with this,
> but then I also worry about the complexity of the change. Again,
> arguably this feature is the correct and safe behavior, so I'm wary of
> adding unnecessary complexity to account for something that should be
> discouraged.

Thanks for the detailed overview of the options! When replying to the
previous email, I had had in mind specifically the PDO attribute (or
mysqli option) because it seems to be the de-facto standard for opting
in for database features. Inlike an .ini option, it's explicit and
doesn't require library maintainer to figure out the interpreter's
parameters. I'd appreciate considering PDO attr/mysqli option as an
alternative to just using `COM_RESET_CONNECTION` unconditionally to
avoid the BC break that looks easily avoidable.

I don't have numbers to support the argument but with some prior
experience, I can easily imagine a bloody enterprise where a DBA is in
another orgchart branch than developers and someone's forced to use what
they have because enforcing an upgrade is out of their power. Also, I
did see some load balancers with significant overhead that effectively
forced developers to use persistent connections (establishing a
connection took tens of milliseconds). In both cases, I think, I'd be
pretty disappointed being left out of PHP 8.6 because of few
conditionals not being added.

Also, apparently it's impossible even to guesstimate the number of
developers that rely on the shared connection's state (even though it's
usually considered a bad practice), but breaking it silently for the
same cost of saving few conditionals doesn't look fair: even a bug that
has been there for too long eventually becomes a feature
(https://xkcd.com/1172/).

So, is it not too late to consider making `COM_RESET_CONNECTION` an
opt-in addition? It's a great one but maybe not leaving out those who
can't (or don't want to) leverage it is safer way to go.

Thanks,
Alex.

Jakub Zelenka

43 days ago

Hi

On Thu, Jul 16, 2026 at 5:24 PM Eric Norris <eric.t.norris@gmail.com> wrote:

> Hello all,
>
> I'm announcing the start of the vote for the "Minimum supported
> versions for PHP 8.6" RFC. The voting will end at 2026-07-30 15:48:00
> UTC. There are multiple votes, one for each minimum version
> requirement.
>
> RFC: https://wiki.php.net/rfc/min_supported_versions_php_8_6
> Discussion: https://news-web.php.net/php.internals/131707
>
>

I don't exactly understand why that Autoconf section does not mention that
it is not available on distro levels for RHEL 8 and 9 so it makes things
difficult for packagers like Remi who explicitly asked to delay it:
https://github.com/php/php-src/pull/21159#issuecomment-4287762254 ? This is
quite strange because you even linked Tim's question and considering that
the Remi's preference is to delay, it obviously means that there are likely
some plans to package 8.6 for those distros and this change will just make
it harder. I don't see reason to rush it to 8.6 and make life harder for
packagers so I voted no.

It's my fault that I haven't read it sooner but the generic title made it
easier to not notice it...

Kind regards,

Jakub

Tim Düsterhus

43 days ago

Hi

On 2026-07-20 19:24, Jakub Zelenka wrote:

> I don't exactly understand why that Autoconf section does not mention
> that
> it is not available on distro levels for RHEL 8 and 9 so it makes
> things
> difficult for packagers like Remi who explicitly asked to delay it:

The proposal clearly specifies the minimum versions for various distros.

> https://github.com/php/php-src/pull/21159#issuecomment-4287762254 ?
> This is
> quite strange because you even linked Tim's question and considering
> that

The question has been left unanswered. Since the only reply was a vague
“I prefer to wait”, I proceeded with writing the RFC.

> the Remi's preference is to delay, it obviously means that there are
> likely
> some plans to package 8.6 for those distros and this change will just
> make
> it harder. I don't see reason to rush it to 8.6 and make life harder
> for
> packagers so I voted no.

I consider being able to properly rely on C11 functionality to be worth
it. Generally speaking, compilers on operating systems that don’t have
autoconf 2.71 likely also don’t (fully) support C11, the lack of a
modern autoconf is really just a canary there.

Best regards
Tim Düsterhus

Jakub Zelenka

43 days ago

Hi,

On Mon, Jul 20, 2026 at 7:48 PM Tim Düsterhus <tim@bastelstu.be> wrote:

> Hi
>
> On 2026-07-20 19:24, Jakub Zelenka wrote:
> > I don't exactly understand why that Autoconf section does not mention
> > that
> > it is not available on distro levels for RHEL 8 and 9 so it makes
> > things
> > difficult for packagers like Remi who explicitly asked to delay it:
>
> The proposal clearly specifies the minimum versions for various distros.
>
>

Well but it's pretty confusing for voters because they don't know that our
minimum target is RHEL 8 which we have been using for deciding about
minimum versions before. The fact that this even goes through RFC in this
form is not good because we should rather have a general policy about
minimum of supported distros that PHP is built on and set minimum deps
versions based on that. This just hides this fact and for voters that have
no idea what the supported distro versions are as this is very hard to
notice.

> > https://github.com/php/php-src/pull/21159#issuecomment-4287762254 ?
> > This is
> > quite strange because you even linked Tim's question and considering
> > that
>
> The question has been left unanswered. Since the only reply was a vague
> “I prefer to wait”, I proceeded with writing the RFC.
>
>

Well, that seems kind of clear to me that some possibility is there
otherwise there wouldn't be such preference.

> > the Remi's preference is to delay, it obviously means that there are
> > likely
> > some plans to package 8.6 for those distros and this change will just
> > make
> > it harder. I don't see reason to rush it to 8.6 and make life harder
> > for
> > packagers so I voted no.
>
> I consider being able to properly rely on C11 functionality to be worth
> it. Generally speaking, compilers on operating systems that don’t have
> autoconf 2.71 likely also don’t (fully) support C11, the lack of a
> modern autoconf is really just a canary there.
>
>

Do you have some specific problems and why does it need to be enforced just
before the feature freeze and cannot wait longer?

Kind regards,

Jakub

Tim Düsterhus

42 days ago

Hi

On 2026-07-20 20:13, Jakub Zelenka wrote:

>> On 2026-07-20 19:24, Jakub Zelenka wrote:
>> > I don't exactly understand why that Autoconf section does not mention
>> > that
>> > it is not available on distro levels for RHEL 8 and 9 so it makes
>> > things
>> > difficult for packagers like Remi who explicitly asked to delay it:
>>
>> The proposal clearly specifies the minimum versions for various
>> distros.
>>
>>
> Well but it's pretty confusing for voters because they don't know that
> our
> minimum target is RHEL 8 which we have been using for deciding about
> minimum versions before. The fact that this even goes through RFC in
> this

Depending on how you look at it, RHEL 8 is either already EOL or will
live until 2033. Halting all library upgrades for another 7 years is
neither in the interest of PHP users and maintainers.

> form is not good because we should rather have a general policy about
> minimum of supported distros that PHP is built on and set minimum deps
> versions based on that. This just hides this fact and for voters that
> have
> no idea what the supported distro versions are as this is very hard to
> notice.

As the RFC states, the autoconf requirement only *affects builds from
git*. The official releases from the PHP project include a ready-made
`./configure` script and thus do not require autoconf to build PHP. This
is similar to ext/uri and the uriparser dependency, where PHP bundles a
working version, but if you are unhappy with that, then you’ll need a
very recent version of the library that may not be provided on older
distros.

>> The question has been left unanswered. Since the only reply was a
>> vague
>> “I prefer to wait”, I proceeded with writing the RFC.
>>
>>
> Well, that seems kind of clear to me that some possibility is there
> otherwise there wouldn't be such preference.

From what I see and understand, the core RHEL 8 distribution only
provides PHP 7.2, any newer PHP version requires the use of external
repositories - or a custom build. If you don’t want to rely on the
PHP-provided `./configure` script, then autoconf 2.71 would similarly be
available in external repositories (EPEL).

>> I consider being able to properly rely on C11 functionality to be
>> worth
>> it. Generally speaking, compilers on operating systems that don’t have
>> autoconf 2.71 likely also don’t (fully) support C11, the lack of a
>> modern autoconf is really just a canary there.
>>
>>
> Do you have some specific problems and why does it need to be enforced
> just
> before the feature freeze and cannot wait longer?

I have various pending PRs to clean up custom implementations for things
that are guaranteed by C11. But these naturally require that we actually
can rely on C11 in practice with proper checks rather than an
easy-to-miss note in the documentation.

With regard to the timing, it was just convenient to bundle the two
upgrades together and I relied on Eric to handle the RFC stuff. Given
that it's cleanup-only and the first Alphas have already been released,
I'd be okay with delaying the merge of the autoconf upgrade for (early)
PHP 8.7.

Best regards
Tim Düsterhus

Eric Norris

33 days ago

On Thu, Jul 16, 2026 at 11:22 AM Eric Norris <eric.t.norris@gmail.com> wrote:

>
> Hello all,
>
> I'm announcing the start of the vote for the "Minimum supported
> versions for PHP 8.6" RFC. The voting will end at 2026-07-30 15:48:00
> UTC. There are multiple votes, one for each minimum version
> requirement.
>
> RFC: https://wiki.php.net/rfc/min_supported_versions_php_8_6
> Discussion: https://news-web.php.net/php.internals/131707
>
> Thanks!
> Eric

Hello!

The voting period has now ended for this RFC with the following outcomes:

- "Implement autoconf 2.71 requirement as outlined in the RFC?" has
passed, with 27 votes for, 2 against, and 5 abstentions.
- "Implement COM_RESET_CONNECTION requirement as outlined in the RFC?"
has passed, with 26 votes for, 0 against, and 5 abstentions.

Thank you all for your time, and for the time of those who will help
merge the implementations.
Eric