[RFC] [VOTE] Minimum supported versions for PHP 8.6 View as Markdown

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!

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

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.
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