Hi, On Mon, Oct 13, 2025 at 8:41 PM Larry Garfield <[email protected]> wrote:
> On Sun, Oct 12, 2025, at 9:02 AM, Jakub Zelenka wrote: > > On Fri, May 9, 2025 at 12:47 PM Jakub Zelenka <[email protected]> wrote: > >> Hello, > >> > >> I'd like to start discussion for some release process updates defined > in the following RFC / linked PR: > >> > >> RFC: https://wiki.php.net/rfc/policy-release-process-update > >> Policy PR: https://github.com/php/policies/pull/19 > >> > > > > The pull request incorporated some other additions and there are no > > further open review requests. I just updated the RFC with the summary > > of all changes. I plan to open voting early next month so if you have > > any comments, please send them here or to the PR. > > > > Kind regards, > > > > Jakub > > My only pushback is not specific to this PR, but more that this PR would > be a good time to address this existing gap: > > Under Major Version releases > > - Significant userland API backward compatibility breaks SHOULD be > preceded > by the deprecation phase in the previous major version. > > Right now, that deprecation phase could be as little as 15 months, or as > long as 5-6 years (and counting). And when deprecating something, we have > no idea how long it's going to be deprecated before it's removed. That's > decided well after the fact, whenever it's decided (by whatever means) that > PHP.next will be a major this time. > > This is hostile for users, who do not know, and cannot know, how long they > have to address deprecations. Things deprecated in 8.5 (of which there > were many) could be removed as soon as November of 2026. Things deprecated > in 8.1, however, have been deprecated for ~4-5 years now, and also could be > removed in November of 2026. > > I would very much like us to put more structure around deprecations, when > they happen, and the release cycle to support that. Fixing the number of > years between Majors would be ideal, as then everyone can plan better > around deprecations. (Eg, we can say "no deprecations in the last minor of > a series", to ensure all deprecations have at least a 2 year window to > address.) As is, it's still largely guesswork for everyone. > > This is out of scope here. The main point of this document is to state what we already do or do some minor clarification of the rules. This is, however, quite contentious and should be separate to its own RFC. Kind regards, Jakub
