Re: [PHP-DEV] [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