[PHP-DEV] [RFC] [DISCUSSION] ext/gd 2.4 — codec sync, Gd\* OOP API, 2D vector/canvas

Mailing Lists php.internals
1

Hi internals,

I'd like to open discussion on the ext/gd 2.4/php 8.6 RFC:

1. Codec sync and correctness. libgd has drifted a long way from
what's bundled in php-src. This brings it back in line: every codec
run against its upstream compliance corpus, with real correctness
fixes landing as a result (color matching, FreeType bounding
box/baseline for angled text). New codecs: QOI, JPEG XL, UltraHDR.
Existing ones gain what they were missing: GIF animation read/write,
multi-page TIFF, full WebP animation, PNG option exposure, JPEG
reader/writer options, raw metadata (EXIF/XMP/ICC/IPTC) read/write.

2. A new Gd\* OOP surface, additive alongside the existing procedural
API. New methods land directly on GdImage (scale(), rotate(),
transform(), composeFrom(), saveTo(), etc.), but every existing
procedural function (imagecreatetruecolor(), imagejpeg(), ...) keeps
its current signature and behavior unchanged, so legacy code isn't
affected and can be freely mixed with the new methods since both
operate on the same GdImage object. Each codec follows the same shape:
Codec::fromFile/fromString/fromStream and toFile/toString/toStream, an
immutable Info object, and ReadOptions/WriteOptions value objects
designed to accept new options without breaking BC. Anim/multi-page
formats get a streaming Reader/Writer instead of loading everything
into memory.

3. A new 2D vector/canvas API on top of FreeType's rasterizer:
gradients, the full Cairo compositing operator set (correct unbounded
operator and premultiplied alpha semantics), save/restore state stack.
Draws directly into an existing truecolor GdImage's buffer, no copy
in/copy out, so it interleaves with legacy drawing calls on the same
image.

The facade across codecs (fromFile/fromString/fromStream,
toFile/toString/toStream) and the value object options aren't just a
style choice, they're what makes the rest of the roadmap possible
without redesigning the API surface later. New internal image formats
(planned for 2.5/3.x: true 32bit ARGB, floating point buffers for HDR)
slot into the same facade instead of forcing a parallel API
(imagecreatetruecolor/palette now f.e.). New codecs follow the
identical pattern by construction (all the imagecreatefrom*/or
image<codec> with different options etc).

And the fluent, chainable method style on GdImage (or/and Gd\Image
later) is built so a future streaming/pipeline mode drops in as a
single new entry method feeding the same chain, not a separate API to
learn. This is a deliberate design constraint of the RFC, not an open
question.

Implementation: GitHub - pierrejoye/php-src-syncgd: Fork to sync gd to 2.4/3.0 · GitHub
libgd only sync already merged in php-src as a separate PR:
Sync gd 2 4 by pierrejoye · Pull Request #22532 · php/php-src · GitHub

This is a discussion thread, not yet a vote. Feedback on scope and
anything in the stubs is very welcome.

Discussions open for 14 days, until 2026/08/01.

Implementation is almost fully complete. I was thinking of adding and
exposing a quantization method as well so users can more easily select
which quantization mode to use (nnquant, legacy f.e.).

I added links to the stubs, I tried to have them in the RFC but it
became not very readable and too lengthy without bringing necessarily
more value in the RFC itself. Happy to add them back if desired (maybe
at the end).

Doing some cleaning and I will create the PR as well before Monday. A
first PR, which took a long time to get approved. I merged myself a
few days ago. Most of the ext/gd/libgd sync is in place already (full
BC but 2 fixes, see the link to the PR in the rfc).

Thanks,
--
Pierre

@pierrejoye

2

Hi

On 7/18/26 20:42, Pierre Joye wrote:

I'd like to open discussion on the ext/gd 2.4/php 8.6 RFC:

PHP: rfc:ext-gd-2.4

[…]

This is a discussion thread, not yet a vote. Feedback on scope and
anything in the stubs is very welcome.

I've given the RFC a very very quick skim:

1. There are some rendering issues / broken markup that make to me greatly reduce the readability. One example would be “for example ``Gd\Png``, ``Gd\Jpeg``, ``Gd\Webp``, and ``Gd\Bmp``” where the double-backticks are emitted as-is and not interpreted.

I recommend using the `<php>…</php>` tags around all inline PHP code (including class names), it will come with basic syntax highlighting.

2. The proposed exceptions are in violation of the Throwable policy that you can find at: policies/coding-standards-and-naming.rst at main · php/policies · GitHub. In particular you need a “GdException extends \Exception” base exception, and must never inherit from RuntimeException.

3. The stub for Gd\Image contains another class Image declaration.

4. The named constructors for GdImage should probably be named consistently with Dom\Document: php-src/ext/dom/php_dom.stub.php at 0fdd7ab9f1382b58b6837be138a1a25644495485 · php/php-src · GitHub

Discussions open for 14 days, until 2026/08/01.

Just 14 days is likely a little short for an RFC of this size. But there is no need to rush it: The window for PHP 8.6 has already closed for all new RFCs or RFCs with a major change.

Best regards
Tim Düsterhus

3

Hi Tim,

On Sun, Jul 19, 2026 at 8:35 PM Tim Düsterhus <tim@bastelstu.be> wrote:

1. There are some rendering issues / broken markup that make to me
greatly reduce the readability. One example would be “for example
``Gd\Png``, ``Gd\Jpeg``, ``Gd\Webp``, and ``Gd\Bmp``” where the
double-backticks are emitted as-is and not interpreted.

I will fix those :slight_smile:

I recommend using the `<php>…</php>` tags around all inline PHP code
(including class names), it will come with basic syntax highlighting.

ah, I will update it, and maybe the syntax page while at it.

2. The proposed exceptions are in violation of the Throwable policy that
you can find at:
policies/coding-standards-and-naming.rst at main · php/policies · GitHub.
In particular you need a “GdException extends \Exception” base
exception, and must never inherit from RuntimeException.

That was in the question,I was not sure. I will update.

4. The named constructors for GdImage should probably be named
consistently with Dom\Document:
php-src/ext/dom/php_dom.stub.php at 0fdd7ab9f1382b58b6837be138a1a25644495485 · php/php-src · GitHub

I will check and update accordingly.

> Discussions open for 14 days, until 2026/08/01.

Just 14 days is likely a little short for an RFC of this size. But there
is no need to rush it: The window for PHP 8.6 has already closed for all
new RFCs or RFCs with a major change.

No, it is not closed. Features freeze is not here yet. And if the PR
review process was not taking so long to get approved there and not
only here, that RFC would have been sent 3 weeks ago :). Something I
am looking at to see what could be improved. Current default reviewers
do an amazing job. It is simply too much cognitive weight for all the
areas and the amount of PRs. Other topic.

Aslo, everything new is added on top. So as all RFCs, during the
discussions we can tweak the details if needed. And the implementation
is already almost complete.

Cheers,
--
Pierre

@pierrejoye

4

On Sun, Jul 19, 2026 at 8:59 PM Pierre Joye <pierre.php@gmail.com> wrote:

> 4. The named constructors for GdImage should probably be named
> consistently with Dom\Document:
> php-src/ext/dom/php_dom.stub.php at 0fdd7ab9f1382b58b6837be138a1a25644495485 · php/php-src · GitHub

I will check and update accordingly.

I checked and I don't think it adds any value or makes it easier to
understand. Similarly other extensions use a shorter self explanation
from*, like the upcoming Duration class' fromSeconds etc.

Cheers,
--
Pierre

@pierrejoye

5

Hi Tim,

On Sun, Jul 19, 2026 at 8:35 PM Tim Düsterhus <tim@bastelstu.be> wrote:

2. The proposed exceptions are in violation of the Throwable policy that
you can find at:
policies/coding-standards-and-naming.rst at main · php/policies · GitHub.
In particular you need a “GdException extends \Exception” base
exception, and must never inherit from RuntimeException.

fixed, it now has a base Gd\GdException. All other new exceptions extend it.

3. The stub for Gd\Image contains another class Image declaration.

Fixed

Cheers,
--
Pierre

@pierrejoye

6

Hi,

Il 19/07/2026 15:35, Tim Düsterhus ha scritto:

On 7/18/26 20:42, Pierre Joye wrote:

Discussions open for 14 days, until 2026/08/01.

Just 14 days is likely a little short for an RFC of this size. But there is no need to rush it: The window for PHP 8.6 has already closed for all new RFCs or RFCs with a major change.

As much as I like this RFC, I'm afraid it came in a little too late.

According to our reminders:

Any RFC intended for inclusion in PHP 8.6 must have its discussion concluded and its voting closed before August 13

which isn't technically possible for this RFC if the voting period has to be two weeks, even if no major discussion or modification happens.

Unless my calculations are off, of course.

Cheers
--
Matteo Beccati

7

Hi Matteo,

On Mon, Jul 20, 2026 at 4:59 PM Matteo Beccati <php@beccati.com> wrote:

Hi,

Il 19/07/2026 15:35, Tim Düsterhus ha scritto:
> On 7/18/26 20:42, Pierre Joye wrote:
>>
>> Discussions open for 14 days, until 2026/08/01.

According to our reminders:

> Any RFC intended for inclusion in PHP 8.6 must have its discussion concluded and its voting closed before August 13

which isn't technically possible for this RFC if the voting period has
to be two weeks, even if no major discussion or modification happens.

Unless my calculations are off, of course.

I want to push back on applying that deadline the same way here. I
co-introduced the RFC process. And the RFC process, the
14-day/deadline mechanism, was designed to reduce/remove risk of
unbuilt changes, or having last minute additions without public
discussions, during the final release stages. It was designed not to
gate something that's already implemented and ready to be merged
before the final stage (if votes pass). That distinction matters a
lot. And it matters even more in my context given another bureaucratic
process prevented me from posting this RFC before.

On timing, the delay getting this posted wasn't from a lack of
readiness, it was internal review process friction, a required PR
approval that wasn't actually being handled in the PR itself, just
assigned to a bot reviewer. I ended up merging it myself last week
rather than wait longer on that.

The reason 8.6 matters isn't convenience. These new APIs are ready and
don't require any BC break to land now.The existing ext/gd functions
remain untouched. But PHP 9 is the only point where option or default
changes become possible, and having the APIs in place before 9 is what
lets us use real-world usage to inform any such adjustments at that
boundary. Miss this window, and that option is gone until the next
major, years away, meaning we'd be locked into today's design choices
for that entire span. I don't think we should lose that purely on a
process technicality, especially for an RFC that's already
implemented.

Cheers,

--
Pierre

@pierrejoye

8

On Mon, Jul 20, 2026 at 12:01 PM Matteo Beccati <php@beccati.com> wrote:

Hi,

Il 19/07/2026 15:35, Tim Düsterhus ha scritto:

On 7/18/26 20:42, Pierre Joye wrote:

Discussions open for 14 days, until 2026/08/01.

Just 14 days is likely a little short for an RFC of this size. But there
is no need to rush it: The window for PHP 8.6 has already closed for all
new RFCs or RFCs with a major change.
As much as I like this RFC, I’m afraid it came in a little too late.

According to our reminders:

Any RFC intended for inclusion in PHP 8.6 must have its discussion concluded and its voting closed before August 13

which isn’t technically possible for this RFC if the voting period has
to be two weeks, even if no major discussion or modification happens.

Unless my calculations are off, of course.

Your calculation is correct - this RFC must not target 8.6 as there is not enough time. This is clearly specified in our policy:

https://github.com/php/policies/blob/main/release-process.rst#beta-releases

Kind regards

Jakub

9

On 20 July 2026 10:59:19 BST, Matteo Beccati <php@beccati.com> wrote:

As much as I like this RFC, I'm afraid it came in a little too late.

According to our reminders:

Any RFC intended for inclusion in PHP 8.6 must have its discussion concluded and its voting closed before August 13

which isn't technically possible for this RFC if the voting period has to be two weeks, even if no major discussion or modification happens.

Unless my calculations are off, of course.

Just to confirm this with reference to policy:

- policies/release-process.rst at main · php/policies · GitHub lists feature freeze as "$rd + 40", and states that all RFCs must be approved by that date
- policies/feature-proposals.rst at main · php/policies · GitHub requires a minimum 14 day "cooldown period" from the initial announcement, and then a minimum 14 day voting period
- so cut-off is for an RFC to be in its final state by "$rd + 12" (40 - 14 - 14)

$rd is release date of first alpha, which was on July 2nd, so $rd+12 was July 14th.

Any RFC which was announced, or received a "major change", after that date, no longer has time to be approved before feature freeze.

Perhaps this milestone should be added explicitly to the "todo" wiki page in future.

(The release policy actually has an ambiguity: it says alpha1 should be tagged on "first Tuesday in July", but released "before first Thursday in July". This year, the first Thursday came *before* the first Tuesday, so it was impossible to follow both requirements. The RMs apparently took the Thursday as the important deadline, and the tag was created on Tue June 30th, "$rd-2", which seems reasonable. I'll raise a PR if nobody else gets there first.)

Regards,

Rowan Tommins
[IMSoP]

10

On 20 July 2026 11:39:42 BST, Pierre Joye <pierre.php@gmail.com> wrote:

On timing, the delay getting this posted wasn't from a lack of
readiness, it was internal review process friction, a required PR
approval that wasn't actually being handled in the PR itself, just
assigned to a bot reviewer. I ended up merging it myself last week
rather than wait longer on that.

Can you clarify this point - what PR was this, and why did it need to be merged before even announcing the RFC?

Rowan Tommins
[IMSoP]

11

Hi,

On Mon, Jul 20, 2026 at 12:42 PM Pierre Joye <pierre.php@gmail.com> wrote:

Hi Matteo,

On Mon, Jul 20, 2026 at 4:59 PM Matteo Beccati <php@beccati.com> wrote:

Hi,

Il 19/07/2026 15:35, Tim Düsterhus ha scritto:

On 7/18/26 20:42, Pierre Joye wrote:

Discussions open for 14 days, until 2026/08/01.

According to our reminders:

Any RFC intended for inclusion in PHP 8.6 must have its discussion concluded and its voting closed before August 13

which isn’t technically possible for this RFC if the voting period has
to be two weeks, even if no major discussion or modification happens.

Unless my calculations are off, of course.

I want to push back on applying that deadline the same way here. I
co-introduced the RFC process. And the RFC process, the
14-day/deadline mechanism, was designed to reduce/remove risk of
unbuilt changes, or having last minute additions without public
discussions, during the final release stages. It was designed not to
gate something that’s already implemented and ready to be merged
before the final stage (if votes pass). That distinction matters a
lot. And it matters even more in my context given another bureaucratic
process prevented me from posting this RFC before.

There has been significant changes to the RFC process since it was introduced and all is now specified in the policy repository and the timing is just given. No one (including RM) has the authority to do exception. That would require change to the policy.

On timing, the delay getting this posted wasn’t from a lack of
readiness, it was internal review process friction, a required PR
approval that wasn’t actually being handled in the PR itself, just
assigned to a bot reviewer. I ended up merging it myself last week
rather than wait longer on that.

Just to clarify here, we do not have any formal requirement for PR to be approved and many PR’s will not get any approvals. This might change one day but currently this is not a requirement but more just nice to have.

The reason 8.6 matters isn’t convenience. These new APIs are ready and
don’t require any BC break to land now.The existing ext/gd functions
remain untouched. But PHP 9 is the only point where option or default
changes become possible, and having the APIs in place before 9 is what

lets us use real-world usage to inform any such adjustments at that
boundary. Miss this window, and that option is gone until the next
major, years away, meaning we’d be locked into today’s design choices
for that entire span. I don’t think we should lose that purely on a
process technicality, especially for an RFC that’s already
implemented.

We didn’t vote on the next version being major so the next version as it stands is 8.7.

But if you really want to get it merged for 8.6, you would need to do PR without RFC (this is an extension change so it is allowed) and hope that non of the core developers will request RFC (adding label to the PR) before it gets merged or worse in the one month after merging because then you would need to revert it and do the actual RFC. That’s the only way how can this get merged for 8.6.

Kind regards,

Jakub

12

hi Rowan,

A quick side-note, a reply that opens with at least a hello goes a
long way. It costs nothing and it is the difference between a review
and a brush off. We are not bots and don't talk to bots.

On Mon, Jul 20, 2026 at 6:54 PM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:

On 20 July 2026 11:39:42 BST, Pierre Joye <pierre.php@gmail.com> wrote:
>On timing, the delay getting this posted wasn't from a lack of
>readiness, it was internal review process friction, a required PR
>approval that wasn't actually being handled in the PR itself, just
>assigned to a bot reviewer. I ended up merging it myself last week
>rather than wait longer on that.

Can you clarify this point - what PR was this, and why did it need to be merged before even announcing the RFC?

I wonder why replying without actually reading the rfc and the linked
PR you asked about here linked in the RFC? or is there a particular
outcome expected?

However, to answer your question, It was important tot:

1. validate full compatibility of the libgd update with current php on
all platforms and supported features to date
2. it uses some "modern" C features, so a full blown validation on php
CIs is a must have first
3. Actual additions to php are thin layers now added in this thread
RFC. No more "business" logic in the binding itself but if needed to
handle older external versions.

In short, the PR validation runners are numerous and have many
platforms, rules and analyzers that I don't have access to, or
partially using them (asan f.e. but not all archs). It also went
through a security audit, thanks to Volker for doing it :slight_smile:

So doing that part first was a quality and validation step and allowed
the actual features addition RFC to focus on what it does, adding
features.

That being said, I am not sure we realize the state of affairs here.

This is a PR and RFC that massively improves existing functions. Read:
everything under the hood, aside from the new APIs, is fixes and
improvements to what already exists. The new APIs themselves have zero
impact on existing functionality. They prepare PHP 9 and bring a much
more developer friendly way to do image operations. And the recurring
answer, too many times, has been "policies" or "wiki syntax."

This release is still in alpha. Whatever the plan is for the next
beta, we're not at RC yet, and new approved features landing before RC
is exactly what we've reasonably expected before these non pragmatic
policies changes.

I'm not asking to hold the release for this RFC. While I still think
the existing schedule allows such additions to land. For the reasons
explained above. And because what I've described above is wrong, on so
many levels, and I fail to see how PHP reached this point of
bureaucracy.

Cheers,
--
Pierre

@pierrejoye

13

On 21/07/2026 03:18, Pierre Joye wrote:

hi Rowan,

A quick side-note, a reply that opens with at least a hello goes a
long way. It costs nothing and it is the difference between a review
and a brush off. We are not bots and don't talk to bots.

Hi Pierre,

I apologise completely for this. I often forget to add a greeting when editing a reply, particularly on mobile. I definitely do not want to sound rude or inhuman, so I will try to remember to include this in future.

Can you clarify this point - what PR was this, and why did it need to be merged before even announcing the RFC?

I wonder why replying without actually reading the rfc and the linked
PR you asked about here linked in the RFC? or is there a particular
outcome expected?

I worded it that way to make sure I didn't look in the wrong place and jump to the wrong conclusions. But the important part of the question was the "why", which you have answered below.

However, to answer your question, It was important tot:

1. validate full compatibility of the libgd update with current php on
all platforms and supported features to date
2. it uses some "modern" C features, so a full blown validation on php
CIs is a must have first
3. Actual additions to php are thin layers now added in this thread
RFC. No more "business" logic in the binding itself but if needed to
handle older external versions.

That makes sense. I realise it's too late to say now, but it sounds like the RFC text could have been presented *in parallel* to that verification. That would have given more time for people to digest the new user-facing API, and suggest any changes without running as close to the feature freeze.

It's quite common for implementations not to be finalised even when an RFC is voted on, as long as changes don't impact what was agreed in the RFC. The policy that has been formalised explicitly allows for that to happen during the Beta period.

This is a PR and RFC that massively improves existing functions. Read:
everything under the hood, aside from the new APIs, is fixes and
improvements to what already exists. The new APIs themselves have zero
impact on existing functionality. They prepare PHP 9 and bring a much
more developer friendly way to do image operations. And the recurring
answer, too many times, has been "policies" or "wiki syntax."

I understand your frustration, and from what I've read, it looks like a really great addition to the language.

But I do think its important that new features are given the time and attention needed to refine small details. Names of new keywords or classes, signatures of new methods, etc, are generally very easy to change during an RFC discussion, but very hard to change once it's made it into a stable release.

On the other hand, it's useful to have a cut-off point for new features somewhere in the release process. If an RFC is in discussion close to that cut-off point, there's always going to be an awkward decision: do we cut off discussion because we're running out of time for the release, or do we push the feature back a year so we can have the proper discussion?

Although it feels like bureaucracy, having a pre-determined cut-off date can in theory make that decision easier: we don't have to debate for every RFC whether it's "small enough" or "important enough" to carry on discussing, we just have to ask "is it ready in time for the cut-off?"

This release is still in alpha. Whatever the plan is for the next
beta, we're not at RC yet, and new approved features landing before RC
is exactly what we've reasonably expected before these non pragmatic
policies changes.

I'm not sure how strictly it was previously enforced, but the release cycle update RFC from two years ago refers to the requirement for RFCs to be voted before beta (but not necessarily merged) as an existing policy: PHP: rfc:release_cycle_update

That RFC actually made that deadline later, because it shortened the overall timeline, moving the feature freeze from July to August; and thus the RFC discussion deadline from June to July.

Wherever that deadline falls, there will always be proposals which, for whatever reason, are written close to it. Naturally, the authors of those proposals will be frustrated at their change being held back until the following year; but on its own, that's not a reason to ignore the agreed cut-off date. Even if we allowed some discretion to land changes after the deadline, it would need some justification - perhaps the RFC is very small, or amends an existing RFC already in the release.

To me, a well-documented process feels fairer than making subjective judgements on the worthiness of every RFC.

I will end, though, by saying I have no particular authority, and this is all just my opinion. I wish you well, and look forward to digging into your proposal, whichever release it ends up targeting.

Regards,

--
Rowan Tommins
[IMSoP]

14

Hi Rowan,

On Tue, Jul 21, 2026 at 7:23 PM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:

On 21/07/2026 03:18, Pierre Joye wrote:
> hi Rowan,
>
> A quick side-note, a reply that opens with at least a hello goes a
> long way. It costs nothing and it is the difference between a review
> and a brush off. We are not bots and don't talk to bots.

Hi Pierre,

I apologise completely for this. I often forget to add a greeting when
editing a reply, particularly on mobile. I definitely do not want to
sound rude or inhuman, so I will try to remember to include this in future.

Thank you, in the age of us talking more to machines than humans, that
is an important point to remind ourselves :).

> However, to answer your question, It was important tot:
>
> 1. validate full compatibility of the libgd update with current php on
> all platforms and supported features to date
> 2. it uses some "modern" C features, so a full blown validation on php
> CIs is a must have first
> 3. Actual additions to php are thin layers now added in this thread
> RFC. No more "business" logic in the binding itself but if needed to
> handle older external versions.

That makes sense. I realise it's too late to say now, but it sounds like
the RFC text could have been presented *in parallel* to that
verification.

yes and no, given the newer C standard, dependencies and similar
changes, if any of that would fail and could not be fixed to be
supported in the current php's supported platforms and required CIs,
it would have forced some refactoring or rewriting. And maybe redo
part of the binding. That's something my time would not allow.

That would have given more time for people to digest the
new user-facing API, and suggest any changes without running as close to
the feature freeze.

It's quite common for implementations not to be finalised even when an
RFC is voted on, as long as changes don't impact what was agreed in the
RFC. The policy that has been formalised explicitly allows for that to
happen during the Beta period.

Right, since day #1 of RFCs :slight_smile:

> This is a PR and RFC that massively improves existing functions. Read:
> everything under the hood, aside from the new APIs, is fixes and
> improvements to what already exists. The new APIs themselves have zero
> impact on existing functionality. They prepare PHP 9 and bring a much
> more developer friendly way to do image operations. And the recurring
> answer, too many times, has been "policies" or "wiki syntax."

I understand your frustration, and from what I've read, it looks like a
really great addition to the language.

But I do think its important that new features are given the time and
attention needed to refine small details. Names of new keywords or
classes, signatures of new methods, etc, are generally very easy to
change during an RFC discussion, but very hard to change once it's made
it into a stable release.

I understand. And realistically, f.e., say there are feedbacks to
update one codec method, or options, how they are named or called,
then all codecs change. They are not different, only different fields
in options.

Other methods like transform. scale or rotate are also pretty standard.

The 2D api is standard canvas-like APIs. Hard to do something
different and end as "php is different so we don't follow what
anything else does" :).

On the other hand, it's useful to have a cut-off point for new features
somewhere in the release process. If an RFC is in discussion close to
that cut-off point, there's always going to be an awkward decision: do
we cut off discussion because we're running out of time for the release,
or do we push the feature back a year so we can have the proper discussion?

Indeed.

Although it feels like bureaucracy, having a pre-determined cut-off date
can in theory make that decision easier: we don't have to debate for
every RFC whether it's "small enough" or "important enough" to carry on
discussing, we just have to ask "is it ready in time for the cut-off?"

And it is.

> This release is still in alpha. Whatever the plan is for the next
> beta, we're not at RC yet, and new approved features landing before RC
> is exactly what we've reasonably expected before these non pragmatic
> policies changes.

I'm not sure how strictly it was previously enforced, but the release
cycle update RFC from two years ago refers to the requirement for RFCs
to be voted before beta (but not necessarily merged) as an existing
policy: PHP: rfc:release_cycle_update

It was pragmatic and meant as a guideline and enforce minimal respect
of internals, RMs, and users. There is an obvious clear difference
between a RFC being accepted now without any implementation and one
with full implementation ready, all new APIs do not affect any
existing codes (obviously) and massively improving almost all existing
functions, for free, zero code change in userland.

That RFC actually made that deadline later, because it shortened the
overall timeline, moving the feature freeze from July to August; and
thus the RFC discussion deadline from June to July.

It makes it as nothing is being actually reviewed but rejected
straight down due to policies. Hence my bureaucracy statement.

Wherever that deadline falls, there will always be proposals which, for
whatever reason, are written close to it. Naturally, the authors of
those proposals will be frustrated at their change being held back until
the following year; but on its own, that's not a reason to ignore the
agreed cut-off date. Even if we allowed some discretion to land changes
after the deadline, it would need some justification - perhaps the RFC
is very small, or amends an existing RFC already in the release.

And the miss is counted in days. And I can already tell that the final
release will be delayed, anyway. Due to other stable branches having
various must have fixes that should be in all stable releases. So all
in all, pure hard core policies instead of pragmatism for the benefits
of our users.

To me, a well-documented process feels fairer than making subjective
judgements on the worthiness of every RFC.

Process has to be humane (thanks to someone well known on linkedin to
remind me of that word ;-). If they are purely for the sake of having
a process, we fail as a project and solve users' needs.

I will end, though, by saying I have no particular authority, and this
is all just my opinion. I wish you well, and look forward to digging
into your proposal, whichever release it ends up targeting.

Nobody has, many accept and confirm rejections. go figure :slight_smile:

Cheers,
--
Pierre

@pierrejoye

15

Hi Pierre,

I should probably make this my last reply in this thread and see if others have anything to add, but I wanted to pick up on one point:

On 23 July 2026 04:35:36 BST, Pierre Joye <pierre.php@gmail.com> wrote:

It makes it as nothing is being actually reviewed but rejected
straight down due to policies. Hence my bureaucracy statement.

I think if this was a small RFC, and people were refusing to read it because of a technicality, that criticism would be justified.

But I'm not sure it's entirely fair in this case. There are maybe twenty sections describing details of the proposal, and the crude "reading time" estimate in Firefox is 47-60 minutes. It may be clear in your head that most of this is uncontroversial, but for anyone else to even make that judgement requires investing a reasonable amount of time.

For many people, spending that time means spending less time on a different discussion. So it's not necessarily about bureaucracy, but a pragmatic decision: it's better to spend time now discussing proposals which are definitely targeting 8.6, and spend time later on proposals which will end up in 8.7.

That trade-off changes if we need to spend time deciding on the target version based on the content of each proposal, which is why I support the idea of a simple rule that everyone agrees in advance.

I do think there's an entirely separate question of *when* that hard cut-off should be. Should RFCs be allowed all the way through the alpha period? Should the alpha period be shorter, or later in some way? I've never been involved enough in the process to answer those questions.

Regards,

Rowan Tommins
[IMSoP]