Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127339
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> <CAEKnhAG399ceuKtk3Hjk0qhnj8rkxsOH4t5kWrmKK7WpphJUEw@mail.gmail.com>
 <0c55c9b700ddac8810974ca62522c3fd@bastelstu.be>
In-Reply-To: <0c55c9b700ddac8810974ca62522c3fd@bastelstu.be>
Date: Tue, 13 May 2025 14:02:56 +0200
Message-ID: <CAEKnhAGsoz5sXxyQedVAzA4VWgVQ4e0s1A0qCQMG2=fk3NAJ7g@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="000000000000422db806350337eb"
From: bukka@php.net (Jakub Zelenka)

--000000000000422db806350337eb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, May 13, 2025 at 12:56=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastelstu.=
be> wrote:

> Hi
>
> Am 2025-05-13 12:13, schrieb Jakub Zelenka:
> >>  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.
>
> We don't currently have any rules at all, except for =E2=80=9Cwhen the RF=
C
> approves the break, then it's okay=E2=80=9D. I was trying to find some gu=
ideline
> for BC breaks that might be okay in a minor (when approved) and BC
> breaks that are never okay in a minor.
>

What I meant is that this would be quite significant change as it could
lead to some sort of bigger breaks when people could think that introducing
break after few years is ok. That's how I understood it but thinking about
it, it would be probably fine if it was an additional restriction (meaning
we would still keep "Syntax backward compatibility SHOULD be preserved").
It would need some good formulation though. So if you can come up with
something that is clear,  I would be happy to add it.


> The application in question is in a very similar position that PHP
> itself is, it has a large public API that "third party" developers rely
> on and a long development history. BC breaks sometimes are not avoidable
> when you try to move forward. Basically the rule of thumb for a breaking
> change in a minor version was that "most third party add-on should be
> adaptable with minimal changes, while remaining compatible with both
> minor versions after making these minimal changes".
>

I understand what you mean. The only challenge is to find a good wording to
the policy. :)

Kind regards

Jakub

--000000000000422db806350337eb
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 Tue, May 13, 2025 at 12:5=
6=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>
Am 2025-05-13 12:13, schrieb Jakub Zelenka:<br>
&gt;&gt;=C2=A0 From my experience in maintaining an old PHP application and=
 <br>
&gt;&gt; upgrading<br>
&gt;&gt; it to support the latest and greatest PHP every year, I think the<=
br>
&gt;&gt; following points would be a good starting point to discuss:<br>
&gt;&gt; <br>
&gt;&gt; - For backwards compatibility breaks introduced in minor versions =
<br>
&gt;&gt; there<br>
&gt;&gt; MUST be a simple (for some appropriate definition of simple) way t=
o<br>
&gt;&gt; adjust the code to be compatible with both the current PHP version=
 and<br>
&gt;&gt; the upcoming version. Ideally the change would be compatible with =
a<br>
&gt;&gt; wider range of past PHP versions (past 3 or so?). It must be a cha=
nge<br>
&gt;&gt; that is simple to perform even with basic tooling (i.e. not requir=
ing <br>
&gt;&gt; an<br>
&gt;&gt; IDE or static analyzers).<br>
&gt;&gt; <br>
&gt; <br>
&gt; If I understand it correctly, this sounds really more like completely =
<br>
&gt; new<br>
&gt; rule that we don&#39;t currently have so I would rather not add it. We=
 <br>
&gt; don&#39;t<br>
&gt; have this relation differences between X.Y and X.(Y+2) to do some extr=
a<br>
&gt; breaks so it&#39;s more for a separate RFC. I&#39;m also not a big fan=
 of such<br>
&gt; change to be honest.<br>
<br>
We don&#39;t currently have any rules at all, except for =E2=80=9Cwhen the =
RFC <br>
approves the break, then it&#39;s okay=E2=80=9D. I was trying to find some =
guideline <br>
for BC breaks that might be okay in a minor (when approved) and BC <br>
breaks that are never okay in a minor.<br></blockquote><div><br></div><div>=
What I meant is that this would be quite significant change as it could lea=
d to some sort of bigger breaks when people could think that introducing br=
eak after few years is ok. That&#39;s how I understood it but thinking abou=
t it, it would be probably fine if it was an additional restriction (meanin=
g we would still keep &quot;Syntax backward compatibility SHOULD be preserv=
ed&quot;). It would need some good formulation though. So if you can come u=
p with something that is clear,=C2=A0 I would be happy to add it.</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">
The application in question is in a very similar position that PHP <br>
itself is, it has a large public API that &quot;third party&quot; developer=
s rely <br>
on and a long development history. BC breaks sometimes are not avoidable <b=
r>
when you try to move forward. Basically the rule of thumb for a breaking <b=
r>
change in a minor version was that &quot;most third party add-on should be =
<br>
adaptable with minimal changes, while remaining compatible with both <br>
minor versions after making these minimal changes&quot;.<br></blockquote><d=
iv><br></div><div>I understand what you mean. The only challenge is to find=
 a good wording to the policy. :)</div><div><br></div><div>Kind regards</di=
v><div><br></div><div>Jakub</div><div>=C2=A0</div><div>=C2=A0</div></div></=
div>

--000000000000422db806350337eb--