Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128837
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 14 Oct 2025 08:35:10 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <28f004ab-76c9-4d5b-8210-1f506133aaa5@app.fastmail.com>
In-Reply-To: 
 <bdeBfZ2id20tU82mxu2kXNYhQkCWwHFN7Iib-k2ozP1Q3Z2Q_gPWnjskvIlUAp-fwNYqDx-rI43loLXplq8y2m9kt4GeZF_ISzxvClWezgE=@gpb.moe>
References: 
 <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
 <CAEKnhAGcioDEYW7fBGOhLxjutcX3OOhXgvmKuMNprGru18HejQ@mail.gmail.com>
 <13c2d58e-b6ff-4fa4-b5b9-c6d39104ba45@app.fastmail.com>
 <bdeBfZ2id20tU82mxu2kXNYhQkCWwHFN7Iib-k2ozP1Q3Z2Q_gPWnjskvIlUAp-fwNYqDx-rI43loLXplq8y2m9kt4GeZF_ISzxvClWezgE=@gpb.moe>
Subject: Re: [PHP-DEV] Re: [RFC][Discussion] Policy release process update
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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