# [RFC] [VOTE] Minimum supported versions for PHP 8.6 - Thread: https://externals.io/message/131975 - Original archive: https://news-web.php.net/php.internals/131975 - Started by Eric Norris on 2026-07-16T15:22:03+00:00 - Messages: 12 - RFC: Minimum supported versions for PHP 8.6 (Accepted) — https://externals.io/rfc/min_supported_versions_php_8_6.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #131975 — Eric Norris — 2026-07-16T15:22:03+00:00 URL: https://externals.io/message/131975#131975 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 --- ## #131981 — Alexander Kurilo — 2026-07-16T19:46:46+00:00 URL: https://externals.io/message/131975#131981 · In reply to: #131975 > 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 --- ## #131985 — Eric Norris — 2026-07-16T21:10:47+00:00 URL: https://externals.io/message/131975#131985 · In reply to: #131981 > > > > […] > > 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! --- ## #132003 — Alexander Kurilo — 2026-07-17T20:15:58+00:00 URL: https://externals.io/message/131975#132003 · In reply to: #131985 > > > […] > 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 > > […] > > 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. --- ## #132005 — Eric Norris — 2026-07-17T23:34:57+00:00 URL: https://externals.io/message/131975#132005 > > > > […] > > 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 > > > […] > > 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. --- ## #132029 — tim@bastelstu.be — 2026-07-19T13:17:26+00:00 URL: https://externals.io/message/131975#132029 · In reply to: #132005 Hi > I don't know if the cost is "just a few conditionals." We'd have two > paths with a PDO 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. I agree with the entire quoted email, and particularly the last paragraph. The “shared nothing” request model of PHP is a huge selling point to make the code easy to reason about and prevent a whole class of bugs. I would consider it a bug that persistent connection can introduce mutable state that outlives a given request and thus supporting and using COM_RESET_CONNECTION is a bugfix in spirit to me. I also find it a reasonable expectation from PHP users, and particularly companies, that when they want to benefit from the latest and greatest PHP that they also keep the rest of their stack current. For the COM_RESET_CONNECTION case the only expectation is that they use a MySQL or MariaDB version that is not EOL. In fact according to EU law such as the GDPR, using software that is no longer supported by updates is extremely risky, since it very likely contains known and unfixed security vulnerabilities. My understanding is that there are other compliance frameworks - such as PCI - that effectively mandate using “maintained software” as well. Best regards Tim Düsterhus --- ## #132055 — Jakub Zelenka — 2026-07-20T17:24:00+00:00 URL: https://externals.io/message/131975#132055 · In reply to: #131975 Hi > 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 --- ## #132056 — tim@bastelstu.be — 2026-07-20T17:48:24+00:00 URL: https://externals.io/message/131975#132056 · In reply to: #132055 Hi > 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 --- ## #132057 — Jakub Zelenka — 2026-07-20T18:13:15+00:00 URL: https://externals.io/message/131975#132057 · In reply to: #132056 Hi, > Hi > > > > […] > > 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. > > […] > > 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. > > […] > > 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 --- ## #132058 — Alexander Kurilo — 2026-07-20T19:25:18+00:00 URL: https://externals.io/message/131975#132058 · In reply to: #132029 > Hi > > > > […] > > I agree with the entire quoted email, and particularly the last > paragraph. The “shared nothing” request model of PHP is a huge selling > point to make the code easy to reason about and prevent a whole class of > bugs. I would consider it a bug that persistent connection can introduce > mutable state that outlives a given request and thus supporting and > using COM_RESET_CONNECTION is a bugfix in spirit to me. While I see your point that it's in "bugfix spirit" and I do belong to the camp of those who'd never ever rely on the shared connection state, we don't know how many applications there are that implicitly or explicitly rely on that behavior that dates back to over 2 decades ago. By implicit, I don't mean necessarily sharing temporary tables and SQL variables. For instance, MariaDB and MySQL appear to behave differently in response to the reset; MariaDB changed it in 2019: * https://bugs.mysql.com/bug.php?id=97633 * https://jira.mariadb.org/browse/MDEV-18281 So, which charset should one expect? Other than that, nearly everywhere there's usually (I checked Java and Python specifically) a method to reset a connection. I would argue PHP should rather give a choice when to reset a connection by exposing a way to execute the command at will and add a convenience layer of issuing (or not issuing) it between processing the requests -- just because a user could totally want a different reset behavior, their own one (which they might have by now), just because `COM_RESET_CONNECTION` is no silver bullet but rather an option. > I also find it a reasonable expectation from PHP users, and particularly > companies, that when they want to benefit from the latest and greatest > PHP that they also keep the rest of their stack current. For the > COM_RESET_CONNECTION case the only expectation is that they use a MySQL > or MariaDB version that is not EOL. In fact according to EU law such as > the GDPR, using software that is no longer supported by updates is > extremely risky, since it very likely contains known and unfixed > security vulnerabilities. My understanding is that there are other > compliance frameworks - such as PCI - that effectively mandate using > “maintained software” as well. By no means do I think that this should not be introduced or using an older database is a good practice. I'm sure, though, we can do better that just add a command without giving the freedom of choice to a user, and there's more to choose than just which version of the database to run. Thanks, Alex --- ## #132067 — tim@bastelstu.be — 2026-07-21T13:51:08+00:00 URL: https://externals.io/message/131975#132067 · In reply to: #132057 Hi > > […] > 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. > > […] > 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). > > […] > 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 --- ## #132140 — Eric Norris — 2026-07-30T16:07:05+00:00 URL: https://externals.io/message/131975#132140 · In reply to: #131975 > > 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