Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128831
Date: Mon, 13 Oct 2025 22:28:47 +0000
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Re: [RFC][Discussion] Policy release process update
Message-ID: <bdeBfZ2id20tU82mxu2kXNYhQkCWwHFN7Iib-k2ozP1Q3Z2Q_gPWnjskvIlUAp-fwNYqDx-rI43loLXplq8y2m9kt4GeZF_ISzxvClWezgE=@gpb.moe>
In-Reply-To: <13c2d58e-b6ff-4fa4-b5b9-c6d39104ba45@app.fastmail.com>
References: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com> <CAEKnhAGcioDEYW7fBGOhLxjutcX3OOhXgvmKuMNprGru18HejQ@mail.gmail.com> <13c2d58e-b6ff-4fa4-b5b9-c6d39104ba45@app.fastmail.com>
Feedback-ID: 96993444:user:proton
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Monday, 13 October 2025 at 19:42, Larry Garfield <larry@garfieldtech.com=
> wrote:
>=20
> My only pushback is not specific to this PR, but more that this PR would =
be a good time to address this existing gap:
>=20
> Under Major Version releases
>=20
> > - Significant userland API backward compatibility breaks SHOULD be prec=
eded
>=20
> by the deprecation phase in the previous major version.
>=20
> 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 n=
o idea how long it's going to be deprecated before it's removed. That's dec=
ided well after the fact, whenever it's decided (by whatever means) that PH=
P.next will be a major this time.
>=20
> This is hostile for users, who do not know, and cannot know, how long the=
y have to address deprecations. Things deprecated in 8.5 (of which there we=
re 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 r=
emoved in November of 2026.
>=20
> 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 y=
ears 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 seri=
es", to ensure all deprecations have at least a 2 year window to address.) =
As is, it's still largely guesswork for everyone.
>=20
> --Larry Garfield

I vehemently disagree with this proposed policy.

Either we move to a system where deprecations are removed in constant inter=
vals, e.g. every 3 years like Python does regardless of what the version nu=
mber 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 release=
d, 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 fricti=
on, 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 wi=
ll get an automatic NO from me.

Best regards,

Gina P. Banyard