Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125804
Precedence: bulk
MIME-Version: 1.0
References: <CAPyeZ4N8GMiLNVCDGxdofcy6txBhng_i2UKUGpiS5bnZ-YcYvA@mail.gmail.com>
 <2A7CF24F-3AE3-4125-965F-C65431C42DFB@gmail.com> <CAPyeZ4MSc=Sw9UE0soCdBEnVAJ8wXHHhYqm88OffkvNLrHPxFw@mail.gmail.com>
 <e966cf16-794d-4827-9a5e-b0de780a5b91@app.fastmail.com> <30a41608-a1ea-40a9-8d2a-c53c508cd89f@jnvsor.net>
 <a6cdfe39-2a18-40b1-8da5-f49e9e7a7918@app.fastmail.com> <CAMrTa2FM4o6q8TXdBbuHfnD66vtqFBVL2Hw6_412Bf1r2T1QMg@mail.gmail.com>
 <CAPyeZ4M0LDzPBTjT_Qa-ccB73DNatGWdARg-mKMO1T1XmnTzUg@mail.gmail.com> <3648840e-5c73-49c9-bc89-105ed761e5c2@scriptfusion.com>
In-Reply-To: <3648840e-5c73-49c9-bc89-105ed761e5c2@scriptfusion.com>
Date: Tue, 15 Oct 2024 10:27:18 +0700
Message-ID: <CAEZPtU4JzVvOkrGpr_LSrMHyVaFh1xTTP6DXgz1JwA=zPqXbyA@mail.gmail.com>
Subject: Re: [PHP-DEV] Asymmetric visibility is a BC break
To: Bilge <bilge@scriptfusion.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009a68df06247b881a"
From: pierre.php@gmail.com (Pierre Joye)

--0000000000009a68df06247b881a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

On Mon, Oct 14, 2024, 8:07=E2=80=AFAM Bilge <bilge@scriptfusion.com> wrote:

> On 14/10/2024 01:02, Valentin Udaltsov wrote:
> > The problem is that in practice most of the PHP libraries consider
> > themselves to be compatible with newer PHP versions.
> >
> > For instance, Symfony PropertyInfo uses `"php": ">=3D8.2"` constraint i=
n
> > its `composer.json`.
>
> That seems like a problem they have created for themselves. It seems an
> error to me to declare software forward-compatible with PHP versions
> that do not yet exist and thus have clearly not been tested against.
> Being as it is an error, we shouldn't consider it impinges on PHP's
> definition of a BC break.
>


As much as I like this new feature and I am more than thankful for the work
behind it, if a test in codes using a x.y version of php works but fails in
x.y+1, it is a BC break, no matter how we look at it. A php dependency
targeting x.* is very common. While it tends to be used less frequently as
the amount of issues increase, that's not necessarly a good thing.

In some cases it is a necessary evil (extension deprecated adding warnings,
security fix requiring a bc break, f.e.).

However, I am very doubtful here. And I do not know if it can be avoided
while keeping the new behaviors.

All in all, it would be great to at least agree that there is a BC break
issue, so it can be addressed according, whatever the final decision is.

best,
Pierre

>

--0000000000009a68df06247b881a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Hello,<br><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Mon, Oct 14, 2024, 8:07=E2=80=AFAM Bilge &lt;=
<a href=3D"mailto:bilge@scriptfusion.com">bilge@scriptfusion.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">On 14/10/2024 01:02, Valentin =
Udaltsov wrote:<br>
&gt; The problem is that in practice most of the PHP libraries consider<br>
&gt; themselves to be compatible with newer PHP versions.<br>
&gt;<br>
&gt; For instance, Symfony PropertyInfo uses `&quot;php&quot;: &quot;&gt;=
=3D8.2&quot;` constraint in<br>
&gt; its `composer.json`.<br>
<br>
That seems like a problem they have created for themselves. It seems an <br=
>
error to me to declare software forward-compatible with PHP versions <br>
that do not yet exist and thus have clearly not been tested against. <br>
Being as it is an error, we shouldn&#39;t consider it impinges on PHP&#39;s=
 <br>
definition of a BC break.<br></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">As much as I like this=
 new feature and I am more than thankful for the work behind it, if a test =
in codes using a x.y version of php works but fails in x.y+1, it is a BC br=
eak, no matter how we look at it. A php dependency targeting x.* is very co=
mmon. While it tends to be used less frequently as the amount of issues inc=
rease, that&#39;s not necessarly a good thing.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">In some cases it is a necessary evil (extension depr=
ecated adding warnings, security fix requiring a bc break, f.e.).</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">However, I am very doubtful here.=
 And I do not know if it can be avoided while keeping the new behaviors.=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">All in all, it would=
 be great to at least agree that there is a BC break issue, so it can be ad=
dressed according, whatever the final decision is.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">best,</div><div dir=3D"auto">Pierre</div><div di=
r=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--0000000000009a68df06247b881a--