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
