Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127337
Precedence: bulk
MIME-Version: 1.0
References: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
 <c35111e43fed56ab8e77c5f4fc767f7e@bastelstu.be> <CAEKnhAHuKV8gJZA_2B-XoZ+UT6u0vPAk1Zc+Q6tTGWCnk_YfxQ@mail.gmail.com>
 <08df054856f9076039b5835c0625ee6f@bastelstu.be>
In-Reply-To: <08df054856f9076039b5835c0625ee6f@bastelstu.be>
Date: Tue, 13 May 2025 12:13:19 +0200
Message-ID: <CAEKnhAG399ceuKtk3Hjk0qhnj8rkxsOH4t5kWrmKK7WpphJUEw@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="0000000000002d137c063501af06"
From: bukka@php.net (Jakub Zelenka)

--0000000000002d137c063501af06
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, May 11, 2025 at 10:14=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.=
be> wrote:

> Hi
>
> I gave this some additional thoughts.
>
> Am 2025-05-09 13:36, schrieb Jakub Zelenka:
> >> - A minor version MUST NOT break syntax compatibility (i.e. every PHP
> >> program that compiles must continue to compile).
> >>
> >
> > Added this one
>
> Thinking about this more, I am not sure if having this as a MUST rule
> matches what we did in the past and I'm also not sure if it is useful to
> have. This rule prevents the addition of new keywords, since they might
> conflict with function names. Adding new symbols and adding a new
> keyword is functionally equivalent, both changes would result in a
> compile time error. Singling out the syntax change does not appear to be
> a useful distinction.
>
>
Yeah this make sense. I changed it to SHOULD in the latest version with
some other updates.


> --------------------------
>
>  From my experience in maintaining an old PHP application and upgrading
> it to support the latest and greatest PHP every year, I think the
> following points would be a good starting point to discuss:
>
> - For backwards compatibility breaks introduced in minor versions there
> MUST be a simple (for some appropriate definition of simple) way to
> adjust the code to be compatible with both the current PHP version and
> the upcoming version. Ideally the change would be compatible with a
> wider range of past PHP versions (past 3 or so?). It must be a change
> that is simple to perform even with basic tooling (i.e. not requiring an
> IDE or static analyzers).
>

If I understand it correctly, this sounds really more like completely new
rule that we don't currently have so I would rather not add it. We don't
have this relation differences between X.Y and X.(Y+2) to do some extra
breaks so it's more for a separate RFC. I'm also not a big fan of such
change to be honest.


> - Backwards compatibility breaks in minor versions MUST NOT result in
> silent behavioral differences. Instead any breaking change must be
> "obvious" when executing the program, even when having a
> less-than-stellar test suite.
>
>
I think this makes sense and added this paragraph (with exception of that
less-than-stellar test suite) to the policy.


> Adding new symbols results in a compile time error (immediately obvious)
> and is simple to fix (rename or remove your own implementation).
> Similarly throwing a ValueError for invalid inputs is reasonably easy to
> detect by executing the affected code path (you can't miss an Exception)
> and also simple to fix (don't do that). Changing operator precedence is
> not easy to detect, thus it is unacceptable. Throwing an error when
> single-letter variables (e.g. $i) would be easy to detect, but break
> almost every program, thus would be unacceptable.


This makes sense but might be a bit too specific. Did you mean to also
include it in this policy?

Kind regards

Jakub

--0000000000002d137c063501af06
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 Sun, May 11, 2025 at 10:1=
4=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" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">Hi<br>
<br>
I gave this some additional thoughts.<br>
<br>
Am 2025-05-09 13:36, schrieb Jakub Zelenka:<br>
&gt;&gt; - A minor version MUST NOT break syntax compatibility (i.e. every =
PHP<br>
&gt;&gt; program that compiles must continue to compile).<br>
&gt;&gt; <br>
&gt; <br>
&gt; Added this one<br>
<br>
Thinking about this more, I am not sure if having this as a MUST rule <br>
matches what we did in the past and I&#39;m also not sure if it is useful t=
o <br>
have. This rule prevents the addition of new keywords, since they might <br=
>
conflict with function names. Adding new symbols and adding a new <br>
keyword is functionally equivalent, both changes would result in a <br>
compile time error. Singling out the syntax change does not appear to be <b=
r>
a useful distinction.<br>
<br></blockquote><div><br></div><div>Yeah this make sense. I changed it to =
SHOULD in the latest version with some other updates.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
--------------------------<br>
<br>
=C2=A0From my experience in maintaining an old PHP application and upgradin=
g <br>
it to support the latest and greatest PHP every year, I think the <br>
following points would be a good starting point to discuss:<br>
<br>
- For backwards compatibility breaks introduced in minor versions there <br=
>
MUST be a simple (for some appropriate definition of simple) way to <br>
adjust the code to be compatible with both the current PHP version and <br>
the upcoming version. Ideally the change would be compatible with a <br>
wider range of past PHP versions (past 3 or so?). It must be a change <br>
that is simple to perform even with basic tooling (i.e. not requiring an <b=
r>
IDE or static analyzers).<br></blockquote><div><br></div><div>If I understa=
nd it correctly, this sounds really more like completely new rule that we d=
on&#39;t currently have so I would rather not add it. We don&#39;t have thi=
s relation differences between X.Y and X.(Y+2) to do some extra breaks so i=
t&#39;s more for a separate RFC. I&#39;m also not a big fan of such change =
to be honest.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
- Backwards compatibility breaks in minor versions MUST NOT result in <br>
silent behavioral differences. Instead any breaking change must be <br>
&quot;obvious&quot; when executing the program, even when having a <br>
less-than-stellar test suite.<br>
<br></blockquote><div><br></div><div>I think this makes sense and added thi=
s paragraph (with exception of that less-than-stellar test suite) to the po=
licy.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
Adding new symbols results in a compile time error (immediately obvious) <b=
r>
and is simple to fix (rename or remove your own implementation). <br>
Similarly throwing a ValueError for invalid inputs is reasonably easy to <b=
r>
detect by executing the affected code path (you can&#39;t miss an Exception=
) <br>
and also simple to fix (don&#39;t do that). Changing operator precedence is=
 <br>
not easy to detect, thus it is unacceptable. Throwing an error when <br>
single-letter variables (e.g. $i) would be easy to detect, but break <br>
almost every program, thus would be unacceptable.</blockquote><div><br></di=
v><div>This makes sense but might be a bit too specific. Did you mean to al=
so include it in this policy?</div><div><br></div><div>Kind regards</div><d=
iv><br></div><div>Jakub=C2=A0</div></div></div>

--0000000000002d137c063501af06--