Re: Re: [RFC][Discussion] Policy release process update

On Mon, Oct 13, 2025, at 5:28 PM, Gina P. Banyard wrote: > On Monday, 13 October 2025 at 19:42, Larry Garfield > <larry@garfieldtech.com> wrote: >> >> 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. >> >> --Larry Garfield > > I vehemently disagree with this proposed policy. > > Either we move to a system where deprecations are removed in constant > intervals, e.g. every 3 years like Python does regardless of what the > version number is, > Or we continue our "semver-ish" policy where we only remove > deprecations in major versions. > Users are *not* forced to upgrade to a new major version when it is > released, and restricting when php-src can introduce deprecations is > not something that is practically doable. > A bunch of deprecations were already pushed back from 8.0 to 8.1 > because we were told deprecations in a brand new major release just > adds extra friction, and now you are floating the idea of no > deprecations in the last minor? > Deprecations are basically never planned, because most, if not all, of > them are proposed after someone encounters an oddity in the language. > Contributing to php-src is not easy, and we already have lost > contributors by telling them that they should have proposed X 2-3 years > ago because "now" is inconvenient. > > Any policy that aims to restrict when php-src can or cannot do > something will get an automatic NO from me. > > Best regards, > > Gina P. Banyard There were like 3 or 4 proposals in my spitballing above. I am not wedded to any in particular: My point is that right now, the handling of deprecations and their scheduling is user-hostile. We should fix that. That may involve some inconveniences for Internals, but... everything is a tradeoff. If it's a small inconvenience in return for a much more predictable and reliable release cycle for users, then frankly that's a win. The details I am flexible on and happy to discuss options. --Larry Garfield