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 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/131707Thanks!
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:
-
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. -
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
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/131707Thanks!
EricI'm sorry to bring this up now (I missed the discussion phase) but is
there a reason to makeCOM_RESET_CONNECTIONmandatory? 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!
- 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.
- 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_CONNECTIONdoesn'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!