Hi, On Mon, Jul 20, 2026 at 12:42 PM Pierre Joye <[email protected]> wrote:
> Hi Matteo, > > On Mon, Jul 20, 2026 at 4:59 PM Matteo Beccati <[email protected]> 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
