Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127330
Precedence: bulk
MIME-Version: 1.0
References: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
 <c35111e43fed56ab8e77c5f4fc767f7e@bastelstu.be>
In-Reply-To: <c35111e43fed56ab8e77c5f4fc767f7e@bastelstu.be>
Date: Fri, 9 May 2025 13:36:19 +0200
Message-ID: <CAEKnhAHuKV8gJZA_2B-XoZ+UT6u0vPAk1Zc+Q6tTGWCnk_YfxQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Policy release process update
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b6f0df0634b260d5"
From: bukka@php.net (Jakub Zelenka)

--000000000000b6f0df0634b260d5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, May 9, 2025 at 1:09=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.be=
> wrote:

> Hi
>
> Am 2025-05-09 12:47, schrieb Jakub Zelenka:
> > 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
>
> Thank you. The changes seem to accurately reflect the current practice
> and make sense to me. I however noticed that =E2=80=9CMajor=E2=80=9D and =
=E2=80=9CMinor=E2=80=9D
> versions both effectively have the same allowances. Perhaps we could add
> some additional nuance as to what breaking changes are allowed to be
> approved by an RFC in a minor version, since breaking changes in majors
> should also require an RFC.


Yeah it doesn't make much sense to note that RFC bit. I wanted to say that
breaks
are possible as it's already happening but the wording was not the best.


> Some thoughts:
>
> - A minor version MUST NOT break syntax compatibility (i.e. every PHP
> program that compiles must continue to compile).
>

Added this one


> - Breaking changes in minor versions SHOULD be limited to extensions /
> the API of functions within an extension.
>

I'm not sure about this wording but it's better than it was before so used
that
as well.


> - The addition of deprecations themselves is not considered a breaking
> change (to resolve the discussion that comes up for each and every
> bulk-deprecation RFC, when you convert Deprecations into Exceptions
> that's on you).
>

So this would probably require the full definition of BC break and list thi=
s
as part of it. It might need more point though. I will think about it and
try to
integrate it somehow.


> - The addition of new symbols (e.g. functions or classes) might conflict
> with user-defined classes, but this is not considered a breaking change.
> An RFC should make a best effort to minimize the impact of a new
> function name by choosing among equally good names (but not
> unnecessarily choose a worse name, just because it is less likely to
> break). This is already implied by it being legal to add features
> without an RFC, but would be good to spell out explicitly.
>

Another point for the BC break definition I think.

Kind regards,

Jakub

--000000000000b6f0df0634b260d5
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 Fri, May 9, 2025 at 1:09=
=E2=80=AFPM Tim D=C3=BCsterhus &lt;<a href=3D"mailto:tim@bastelstu.be">tim@=
bastelstu.be</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">Hi<br>
<br>
Am 2025-05-09 12:47, schrieb Jakub Zelenka:<br>
&gt; I&#39;d like to start discussion for some release process updates defi=
ned <br>
&gt; in<br>
&gt; the following RFC / linked PR:<br>
&gt; <br>
&gt; RFC: <a href=3D"https://wiki.php.net/rfc/policy-release-process-update=
" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/policy-rele=
ase-process-update</a><br>
&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><b=
r>
<br>
Thank you. The changes seem to accurately reflect the current practice <br>
and make sense to me. I however noticed that =E2=80=9CMajor=E2=80=9D and =
=E2=80=9CMinor=E2=80=9D <br>
versions both effectively have the same allowances. Perhaps we could add <b=
r>
some additional nuance as to what breaking changes are allowed to be <br>
approved by an RFC in a minor version, since breaking changes in majors <br=
>
should also require an RFC. </blockquote><div><br></div><div>Yeah it doesn&=
#39;t make much sense to note that RFC bit. I wanted to say that breaks</di=
v><div>are possible as it&#39;s already happening but the wording was not t=
he best.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">Some thoughts:<br>
<br>
- A minor version MUST NOT break syntax compatibility (i.e. every PHP <br>
program that compiles must continue to compile).<br></blockquote><div><br><=
/div><div>Added this one</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
- Breaking changes in minor versions SHOULD be limited to extensions / <br>
the API of functions within an extension.<br></blockquote><div><br></div><d=
iv>I&#39;m not sure about this wording but it&#39;s better than it was befo=
re so used that</div><div>as well.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
- The addition of deprecations themselves is not considered a breaking <br>
change (to resolve the discussion that comes up for each and every <br>
bulk-deprecation RFC, when you convert Deprecations into Exceptions <br>
that&#39;s on you).<br></blockquote><div><br></div><div>So this would proba=
bly require the full definition of BC break and list this</div><div>as part=
 of it. It might need more point though. I will think about it and try to</=
div><div>integrate it somehow.</div><div>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">
- The addition of new symbols (e.g. functions or classes) might conflict <b=
r>
with user-defined classes, but this is not considered a breaking change. <b=
r>
An RFC should make a best effort to minimize the impact of a new <br>
function name by choosing among equally good names (but not <br>
unnecessarily choose a worse name, just because it is less likely to <br>
break). This is already implied by it being legal to add features <br>
without an RFC, but would be good to spell out explicitly.<br></blockquote>=
<div><br></div><div>Another point for the BC break definition I think.</div=
><div><br></div><div>Kind regards,</div><div><br></div><div>Jakub=C2=A0</di=
v></div></div>

--000000000000b6f0df0634b260d5--