Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127107
Precedence: bulk
MIME-Version: 1.0
References: <CAPTD5yFaQL58uJ3Focij9HKT-u-70fTDdzBWsqxpAru2YRZaqQ@mail.gmail.com>
In-Reply-To: <CAPTD5yFaQL58uJ3Focij9HKT-u-70fTDdzBWsqxpAru2YRZaqQ@mail.gmail.com>
Date: Mon, 14 Apr 2025 12:36:15 +0200
Message-ID: <CAEKnhAF1X_ivb_P5Nwb-1XqV_FqvYxadCoggx_KjjUAS9ySE=A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility
To: Jorg Sowa <jorg.sowa@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cfd73f0632ba9f77"
From: bukka@php.net (Jakub Zelenka)

--000000000000cfd73f0632ba9f77
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Apr 13, 2025 at 11:09=E2=80=AFPM Jorg Sowa <jorg.sowa@gmail.com> wr=
ote:

> Thank you all for the feedback on the topic of BC breaks in argument
> validation https://news-web.php.net/php.internals/126706
>
> I have collected all concerns, prepared an RFC for this change, and I'm
> opening discussion on its content:
> https://wiki.php.net/rfc/minor-version-compatibility
>
> Since this touches on the broader topic of release policy and BC
> expectations, I=E2=80=99d also like to open the door for related improvem=
ents.
> Rowan raised several valid points that highlight the need for clearer
> communication and expectations around minor version changes. If the
> community feels it's appropriate, I=E2=80=99m happy to include these sugg=
estions in
> the voting. The more clearly BC policy is defined, the less time we=E2=80=
=99ll need
> to spend on debating individual cases in the future.
>
> Rowan=E2=80=99s suggestions included examples like:
>
> Maybe we could work on some criteria that could be applied (and publicise=
d
> to users) about what is and isn't allowed in minor versions.
> For instance:
>
>    -
>
>    Code that already causes fatal behaviour might cause different fatal
>    behaviour (e.g. throwing an Error instead of raising an E_ERROR)
>    -
>
>    Code that directly violates documented types might start throwing
>    TypeError
>    -
>
>    Code that previously returned null for invalid inputs might start
>    throwing ValueError
>
>
This looks a bit too generic to me and it might significantly differ based
on use case as Bob noted. I think we should leave some flexibility and
rather add rules for specific issues where we need some defined approach.
In this case it is handling of errors for cases where only constants are
documented.

Kind regards

Jakub

--000000000000cfd73f0632ba9f77
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 13, 2025 at 11:09=E2=
=80=AFPM Jorg Sowa &lt;<a href=3D"mailto:jorg.sowa@gmail.com" target=3D"_bl=
ank">jorg.sowa@gmail.com</a>&gt; wrote:<br></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"><div dir=3D"ltr"><div><div>Thank you all for the fe=
edback on the topic of BC breaks in argument validation <a href=3D"https://=
news-web.php.net/php.internals/126706" target=3D"_blank">https://news-web.p=
hp.net/php.internals/126706</a><br><br></div>I have collected all concerns,=
 prepared an RFC for this change, and I&#39;m opening discussion on its con=
tent: <a href=3D"https://wiki.php.net/rfc/minor-version-compatibility" targ=
et=3D"_blank">https://wiki.php.net/rfc/minor-version-compatibility</a><br><=
br></div>Since this touches on the broader topic of release policy and BC e=
xpectations, I=E2=80=99d also like to open the door for related improvement=
s. Rowan raised several valid points that highlight the need for clearer co=
mmunication and expectations around minor version changes. If the community=
 feels it&#39;s appropriate, I=E2=80=99m happy to include these suggestions=
 in the voting. The more clearly BC policy is defined, the less time we=E2=
=80=99ll need to spend on debating individual cases in the future.<p>Rowan=
=E2=80=99s suggestions included examples like:</p>
<blockquote>
<p>Maybe we could work on some criteria that could be applied (and publicis=
ed to users) about what is and isn&#39;t allowed in minor versions.<br>
For instance:</p>
<ul><li>
<p>Code that already causes fatal behaviour might cause different fatal beh=
aviour (e.g. throwing an <code>Error</code> instead of raising an <code>E_E=
RROR</code>)</p>
</li><li>
<p>Code that directly violates documented types might start throwing <code>=
TypeError</code></p>
</li><li>
<p>Code that previously returned <code>null</code> for invalid inputs might=
 start throwing <code>ValueError</code></p></li></ul></blockquote></div></b=
lockquote><div><br></div><div>This looks a bit too generic to me and it mig=
ht significantly differ based on use case as Bob noted. I think we should l=
eave some flexibility and rather add rules for specific issues where we nee=
d some defined approach. In this case it is handling of errors for cases wh=
ere only constants are documented.<br></div><div><br></div><div>Kind regard=
s</div><div><br></div><div>Jakub</div></div></div>
</div>

--000000000000cfd73f0632ba9f77--