Hi Rowan, On Tue, Jul 21, 2026 at 7:23 PM Rowan Tommins [IMSoP] <[email protected]> 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 :) > > 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: https://wiki.php.net/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 :) Cheers, -- Pierre @pierrejoye
