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

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

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.

I don't know if the cost is "just a few conditionals." We'd have two
paths with a PDO option:

1. Make it the default, and users can turn it off. Now we need to
   document this option, and explain that you shouldn't turn it off
   unless you've noticed that you are relying on prior connection state.
   In this case, you'd need to (a) know or find out that you're relying
   on it and then (b) make a code change to opt-out. Once you're in the
   position of making a code change to opt out, you're arguably in a
   position to try to fix your code in the first place.

2. Make it off by default, and users can turn it on. Now persistent
   connection users continue to be "unsafe", and we need to document this
   option and explain that you should always turn it on. Some users may
   do this, some may not, maybe people start to develop a "superstition"
   around the option.

I don't like either of these options, and as the RFC author I feel
that the best outcome is to choose the "correct" choice, especially
considering that we are talking about software that is a decade old.
While I can appreciate your argument, I don't think that the pool of
affected users is large enough to warrant anything less than this.