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

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