Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130259
Precedence: list
MIME-Version: 1.0
References: <Sm1GZb5hgsnp0GsxSRFcsRA5FiZoHJMi9368TSt4Qb8Qr61aFDSGxQMP9fpj58uMVwPgynuve8bplPhSZhR4HSnfHUCpoBqInTHWjd-uUyA=@gpb.moe>
In-Reply-To: <Sm1GZb5hgsnp0GsxSRFcsRA5FiZoHJMi9368TSt4Qb8Qr61aFDSGxQMP9fpj58uMVwPgynuve8bplPhSZhR4HSnfHUCpoBqInTHWjd-uUyA=@gpb.moe>
Date: Thu, 5 Mar 2026 09:47:51 +0100
Message-ID: <CAEKnhAHX7GHQuUX5cgDtnJta=OcEt-97yDt1swR=c4Asrn=mfw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Exempt input type and value validation from BC
 Break policy
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008aee41064c42feac"
From: bukka@php.net (Jakub Zelenka)

--0000000000008aee41064c42feac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Mar 2, 2026 at 2:16=E2=80=AFPM Gina P. Banyard <internals@gpb.moe> =
wrote:

> Hello internals,
>
> I would like to propose a short policy RFC to formally exempt input type
> and value validation from our BC Break policy.
> The current wording of the policy already permits us to add validation of
> inputs, but recently any such changes have been asked to submit an RFC
> instead.
> We believe that requiring an RFC for this type of change is detrimental
> and adds unnecessary friction for routine maintenance activity and new
> contributors.
>
> RFC: https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-policy
>
>
Message text is fine and it was my omission not to add it as we change it
already so thanks for that. It might be good to separate vote for this so
it definitely passes.

The ValueError is more problematic because as you can already see with
error_log() $message_type, it is not always that straight forward. I would
prefer we keep those decided on case by case basis which also gives a
better visibility.

Kind regards,

Jakub

--0000000000008aee41064c42feac
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 Mon, Mar 2, 2026 at 2:16=
=E2=80=AFPM Gina P. Banyard &lt;internals@gpb.moe&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Hello internals,<br>
<br>
I would like to propose a short policy RFC to formally exempt input type an=
d value validation from our BC Break policy.<br>
The current wording of the policy already permits us to add validation of i=
nputs, but recently any such changes have been asked to submit an RFC inste=
ad.<br>
We believe that requiring an RFC for this type of change is detrimental and=
 adds unnecessary friction for routine maintenance activity and new contrib=
utors.<br>
<br>
RFC: <a href=3D"https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-=
policy" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/polic=
y-exempt-type-value-error-bc-policy</a><br><br></blockquote><div><br></div>=
<div>Message text is fine and it was my omission not to add it as we change=
 it already so thanks for that. It might be good to separate vote for this =
so it definitely passes.</div><div><br></div><div>The ValueError is more pr=
oblematic because as you can already see with error_log() $message_type, it=
 is not always that straight forward. I would prefer we keep those decided =
on case by case basis which also gives a better visibility.</div><div><br><=
/div><div>Kind regards,</div><div><br></div><div>Jakub</div></div></div>

--0000000000008aee41064c42feac--