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