Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.6

--000000000000b03b6e06579a2610
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 27, 2026 at 4:09=E2=80=AFPM Matteo Beccati <[email protected]> wr=
ote:

> Hi,
>
> > On 2026-07-27 12:31, Gina P. Banyard wrote:
> >> As announced last week I've opened the vote for the 8.6 mass
> >> deprecation RFC:
> >> https://wiki.php.net/rfc/deprecations_php_8_6
> At the time I'm the only one who voted "no" on
> https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_filter
>
> As things currently stand, projects that rely on this functionality
> (notably symfony/http-client and php-http/message) will start triggering
> deprecation notices in PHP 8.6. There are no plans to expose the
> underlying behaviour in an alternative way, despite this concern being
> raised during the discussion period.
>
> I believe we should provide such an alternative together with the
> deprecation, rather than expecting projects with 200M+ installations to
> "find an alternative, such as decoding it using code written in PHP".
>
>
I think this should have not been proposed for deprecation yet. There are
significant users of it and I just didn't have time to properly look into
the issues. So there might be options to get it fixed properly. So I think
it should wait till it's properly investigated.

Kind regards,

Jakub

--000000000000b03b6e06579a2610
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Jul 27,=
 2026 at 4:09=E2=80=AFPM Matteo Beccati &lt;<a href=3D"mailto:[email protected]=
om">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">Hi,<br>
<br>
&gt; On 2026-07-27 12:31, Gina P. Banyard wrote:<br>
&gt;&gt; As announced last week I&#39;ve opened the vote for the 8.6 mass <=
br>
&gt;&gt; deprecation RFC:<br>
&gt;&gt; <a href=3D"https://wiki.php.net/rfc/deprecations_php_8_6" rel=3D"n=
oreferrer" target=3D"_blank">https://wiki.php.net/rfc/deprecations_php_8_6<=
/a><br>
At the time I&#39;m the only one who voted &quot;no&quot; on <br>
<a href=3D"https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_dechunk_=
filter" rel=3D"noreferrer" target=3D"_blank">https://wiki.php.net/rfc/depre=
cations_php_8_6#deprecate_dechunk_filter</a><br>
<br>
As things currently stand, projects that rely on this functionality <br>
(notably symfony/http-client and php-http/message) will start triggering <b=
r>
deprecation notices in PHP 8.6. There are no plans to expose the <br>
underlying behaviour in an alternative way, despite this concern being <br>
raised during the discussion period.<br>
<br>
I believe we should provide such an alternative together with the <br>
deprecation, rather than expecting projects with 200M+ installations to <br=
>
&quot;find an alternative, such as decoding it using code written in PHP&qu=
ot;.<br><br></blockquote><div><br></div><div>I think this should have not b=
een proposed for deprecation yet. There are significant users of it and I j=
ust didn&#39;t have time to properly look into the issues. So there might b=
e options to get it fixed properly. So I think it should wait till it&#39;s=
 properly investigated.=C2=A0</div><div><br></div><div>Kind regards,</div><=
div><br></div><div>Jakub</div></div></div>

--000000000000b03b6e06579a2610--