Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128825
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 13 Oct 2025 13:39:02 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <13c2d58e-b6ff-4fa4-b5b9-c6d39104ba45@app.fastmail.com>
In-Reply-To: 
 <CAEKnhAGcioDEYW7fBGOhLxjutcX3OOhXgvmKuMNprGru18HejQ@mail.gmail.com>
References: 
 <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
 <CAEKnhAGcioDEYW7fBGOhLxjutcX3OOhXgvmKuMNprGru18HejQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC][Discussion] Policy release process update
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Oct 12, 2025, at 9:02 AM, Jakub Zelenka wrote:
> On Fri, May 9, 2025 at 12:47=E2=80=AFPM Jakub Zelenka <bukka@php.net> =
wrote:
>> Hello,
>>=20
>> I'd like to start discussion for some release process updates defined=
 in the following RFC / linked PR:
>>=20
>> RFC: https://wiki.php.net/rfc/policy-release-process-update
>> Policy PR: https://github.com/php/policies/pull/19
>>=20
>
> The pull request incorporated some other additions and there are no=20
> further open review requests. I just updated the RFC with the summary=20
> of all changes. I plan to open voting early next month so if you have=20
> any comments, please send them here or to the PR.
>
> Kind regards,
>
> Jakub

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 h=
ave no idea how long it's going to be deprecated before it's removed.  T=
hat's decided well after the fact, whenever it's decided (by whatever me=
ans) that PHP.next will be a major this time.

This is hostile for users, who do not know, and cannot know, how long th=
ey have to address deprecations.  Things deprecated in 8.5 (of which the=
re were many) could be removed as soon as November of 2026.  Things depr=
ecated in 8.1, however, have been deprecated for ~4-5 years now, and als=
o could be removed in November of 2026.

I would very much like us to put more structure around deprecations, whe=
n they happen, and the release cycle to support that.  Fixing the number=
 of years between Majors would be ideal, as then everyone can plan bette=
r around deprecations.  (Eg, we can say "no deprecations in the last min=
or of a series", to ensure all deprecations have at least a 2 year windo=
w to address.)  As is, it's still largely guesswork for everyone.

--Larry Garfield