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