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: https://wiki.php.net/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]
