Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129051
Precedence: list
MIME-Version: 1.0
References: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
 <CAEKnhAGcioDEYW7fBGOhLxjutcX3OOhXgvmKuMNprGru18HejQ@mail.gmail.com> <13c2d58e-b6ff-4fa4-b5b9-c6d39104ba45@app.fastmail.com>
In-Reply-To: <13c2d58e-b6ff-4fa4-b5b9-c6d39104ba45@app.fastmail.com>
Date: Sun, 2 Nov 2025 13:37:46 +0100
Message-ID: <CAEKnhAFwOfppkjM4-peOV86B_Qmd65tvw00MauwPSR8B3vp8MA@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC][Discussion] Policy release process update
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000059b03806429bdee6"
From: bukka@php.net (Jakub Zelenka)

--00000000000059b03806429bdee6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Oct 13, 2025 at 8:41=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> 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> w=
rote:
> >> Hello,
> >>
> >> I'd like to start discussion for some release process updates defined
> in the following RFC / linked PR:
> >>
> >> RFC: https://wiki.php.net/rfc/policy-release-process-update
> >> Policy PR: https://github.com/php/policies/pull/19
> >>
> >
> > The pull request incorporated some other additions and there are no
> > further open review requests. I just updated the RFC with the summary
> > of all changes. I plan to open voting early next month so if you have
> > 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 hav=
e
> 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) th=
at
> PHP.next will be a major this time.
>
> 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
> were many) could be removed as soon as November of 2026.  Things deprecat=
ed
> 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.
>
>
This is out of scope here. The main point of this document is to state what
we already do or do some minor clarification of the rules. This is,
however, quite contentious and should be separate to its own RFC.

Kind regards,

Jakub

--00000000000059b03806429bdee6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Oct 13, 2025 at 8:41=
=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfieldtech.com">la=
rry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">On Sun, Oct 12, 2025, at 9:02 AM, Jakub Zelenka wrote:<=
br>
&gt; On Fri, May 9, 2025 at 12:47=E2=80=AFPM Jakub Zelenka &lt;<a href=3D"m=
ailto:bukka@php.net" target=3D"_blank">bukka@php.net</a>&gt; wrote:<br>
&gt;&gt; Hello,<br>
&gt;&gt; <br>
&gt;&gt; I&#39;d like to start discussion for some release process updates =
defined in the following RFC / linked PR:<br>
&gt;&gt; <br>
&gt;&gt; RFC: <a href=3D"https://wiki.php.net/rfc/policy-release-process-up=
date" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/policy-=
release-process-update</a><br>
&gt;&gt; Policy PR: <a href=3D"https://github.com/php/policies/pull/19" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/php/policies/pull/19</=
a><br>
&gt;&gt; <br>
&gt;<br>
&gt; The pull request incorporated some other additions and there are no <b=
r>
&gt; further open review requests. I just updated the RFC with the summary =
<br>
&gt; of all changes. I plan to open voting early next month so if you have =
<br>
&gt; any comments, please send them here or to the PR.<br>
&gt;<br>
&gt; Kind regards,<br>
&gt;<br>
&gt; Jakub<br>
<br>
My only pushback is not specific to this PR, but more that this PR would be=
 a good time to address this existing gap:<br>
<br>
Under Major Version releases<br>
&gt;=C2=A0 =C2=A0-=C2=A0 Significant userland API backward compatibility br=
eaks SHOULD be preceded<br>
=C2=A0 =C2=A0 =C2=A0 by the deprecation phase in the previous major version=
.<br>
<br>
Right now, that deprecation phase could be as little as 15 months, or as lo=
ng as 5-6 years (and counting).=C2=A0 And when deprecating something, we ha=
ve no idea how long it&#39;s going to be deprecated before it&#39;s removed=
.=C2=A0 That&#39;s decided well after the fact, whenever it&#39;s decided (=
by whatever means) that PHP.next will be a major this time.<br>
<br>
This is hostile for users, who do not know, and cannot know, how long they =
have to address deprecations.=C2=A0 Things deprecated in 8.5 (of which ther=
e were many) could be removed as soon as November of 2026.=C2=A0 Things dep=
recated in 8.1, however, have been deprecated for ~4-5 years now, and also =
could be removed in November of 2026.<br>
<br>
I would very much like us to put more structure around deprecations, when t=
hey happen, and the release cycle to support that.=C2=A0 Fixing the number =
of years between Majors would be ideal, as then everyone can plan better ar=
ound deprecations.=C2=A0 (Eg, we can say &quot;no deprecations in the last =
minor of a series&quot;, to ensure all deprecations have at least a 2 year =
window to address.)=C2=A0 As is, it&#39;s still largely guesswork for every=
one.<br><br></blockquote><div><br></div><div>This is out of scope here. The=
 main point of this document is to state what we already do or do some mino=
r clarification of the rules. This is, however, quite contentious and shoul=
d be separate to its own RFC.</div><div><br></div><div>Kind regards,</div><=
div><br></div><div>Jakub</div></div></div>

--00000000000059b03806429bdee6--