On Mon, Oct 13, 2025, at 5:28 PM, Gina P. Banyard wrote: > On Monday, 13 October 2025 at 19:42, Larry Garfield > <[email protected]> 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
