Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128674
Precedence: list
MIME-Version: 1.0
References: <CAOWwgpk1Z_bns=Z55TqpYOBXvBGpurMfjTGPSgQ6Uf5QXfLOjg@mail.gmail.com>
 <CALaXqqRBRJdMO0Jvguj57M5U2nTVn_3DK6bB433RBmWvHuA-wA@mail.gmail.com>
In-Reply-To: <CALaXqqRBRJdMO0Jvguj57M5U2nTVn_3DK6bB433RBmWvHuA-wA@mail.gmail.com>
Date: Thu, 11 Sep 2025 18:51:55 +0200
Message-ID: <CAOWwgp==2KHZGNHQ3x7pSP-Y6cGhdy7nqEpxPCHKpyCv3vcdLg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()
To: Daniel Scherzer <daniel.e.scherzer@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008a47df063e895be4"
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000008a47df063e895be4
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Daniel,

Thanks for the update.

Le lun. 8 sept. 2025 =C3=A0 19:25, Daniel Scherzer <daniel.e.scherzer@gmail=
.com>
a =C3=A9crit :

> On Mon, Sep 8, 2025 at 8:21=E2=80=AFPM Nicolas Grekas <
> nicolas.grekas+php@gmail.com> wrote:
>
>> Hello internals,
>>
>> Following the discussion that started at
>> https://externals.io/message/128226#128456 I wrote this RFC to formalize
>> our consensus on the topic.
>>
>> TL;DR, this is about converting the deprecation of __sleep and __wakeup
>> to a documentation-based soft deprecation:
>> https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup
>>
>> Cheers,
>> Nicolas
>>
>
> The PHP 8.5 RM team has discussed this internally, and arrived at the
> following. A full explanation of our reasoning follows.
>
> - Given the accepted RFC for deprecating `__sleep()` and `__wakeup()` in
> PHP 8.5, we should aim to merge the deprecation in time for PHP 8.5, i.e.
> before PHP-8.5 is branched on September 23.
> - If the RFC to switch the deprecation to a "soft deprecation" is
> accepted, the RM team is comfortable with landing a revert of the
> deprecation as long as the revert can land before RC2.
>
> Our reasoning is as follows ("hard deprecation" means the warnings, "soft
> deprecation" is just the documentation):
>
> 1. We cannot assume that the soft deprecation RFC will be accepted.
> However, if we wait until we know for certain that the RFC fails, it woul=
d
> be too late to *then* merge the hard deprecation. By our math, if the sof=
t
> deprecation RFC had exactly 2 weeks of discussion and then 2 weeks of
> voting, the earliest it would close is October 4, with RC*2* being tagged
> October 7.
>
> 2. Since we cannot merge the hard deprecation after RC1, the hard
> deprecation either needs to go into PHP 8.5 before RC1, or be delayed unt=
il
> the next release. Since there was an RFC for doing the deprecation in PHP
> 8.5 that got accepted, 8.5 should be preferred.
>
> 3. Having a hard deprecation in PHP 8.5, and converting it to a soft
> deprecation in PHP 8.6 (or PHP 9.0, whatever is next), does not make sens=
e.
> For the soft deprecation RFC to be meaningful, we would need to not have
> the hard deprecation warnings in PHP 8.5.
>
> 4. If the hard deprecation is implemented for 8.5 (per note 2) but the
> soft deprecation RFC is accepted, then (per note 3) we should remove the
> hard deprecation warnings from PHP 8.5. However, such a relatively large
> change should not be made too close to the GA release of PHP 8.5.0. Relea=
se
> candidates are meant to match the eventual release as closely as possible=
.
>
> 5. Given the minimum schedule outlined in note 1 above, there are a few
> days before the soft deprecation RFC could finish voting and when RC2 is
> packaged. This should be enough time to land a revert of the hard
> deprecation, given that a) the patch can be reviewed and approved before
> the RFC finishes, and b) the patch is likely to be just a revert of the
> original deprecation patches. By removing the warnings from RC2, communit=
y
> developers waiting to test the release candidates until after the warning=
s
> were removed can have 3 release candidates to do so.
>

The interesting thing with that approach is that all libs that do test
with php-src dev-master will see the deprecation, so at least some OSS
maintainers will work on addressing this as we speak.
This might give useful hints about the impact of the deprecation (like the
feedback from Sebastian on phpunit, followed by one from Thomas stating
this resulted in a perf issue).
On Symfony, we have 3 branches maintained: the next major is already free
from sleep/wakeup; the next minor has BC layers that look like the ones
presented in the RFC; and the next patch-level is not free from the
deprecation: we addressed throwing/internal/final cases and chose the
option to silence in the CI instead for the complex cases. The CI is still
not green: dependencies will have to be patched also. I've no idea how much
time this will take. But I know it's a significant effort - way more than
usual for a deprecation!

As a corollary to your message, I'm wondering what would be the earliest we
could open the vote?
Our policy on the topic says:

> There'd be a minimum of 2 weeks between when an RFC that touches the
> language is brought up on this list and when it's voted on is required.
> Other RFCs might use a smaller timeframe, but it should be at least a wee=
k.


Should it be one or two weeks?
The earlier the better for everyone I think (I don=E2=80=99t expect to conv=
ince Tim
either way, so from my side that part of the discussion is done. ;) )

Cheers,
Nicolas

--0000000000008a47df063e895be4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Daniel,</div><div><br></div><div>=
Thanks for the update.</div></div><br><div class=3D"gmail_quote gmail_quote=
_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0lun. 8 sept. 2025=
 =C3=A0=C2=A019:25, Daniel Scherzer &lt;<a href=3D"mailto:daniel.e.scherzer=
@gmail.com">daniel.e.scherzer@gmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div d=
ir=3D"ltr">On Mon, Sep 8, 2025 at 8:21=E2=80=AFPM Nicolas Grekas &lt;<a hre=
f=3D"mailto:nicolas.grekas%2Bphp@gmail.com" target=3D"_blank">nicolas.greka=
s+php@gmail.com</a>&gt; wrote:</div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hello internals=
,</div><div><br></div><div>Following the discussion that started at <a href=
=3D"https://externals.io/message/128226#128456" target=3D"_blank">https://e=
xternals.io/message/128226#128456</a> I wrote this RFC to formalize our con=
sensus=C2=A0on the topic.</div><div><br></div><div>TL;DR, this is about con=
verting the deprecation of __sleep and __wakeup to a documentation-based so=
ft deprecation:</div><div><a href=3D"https://wiki.php.net/rfc/soft-deprecat=
e-sleep-wakeup" target=3D"_blank">https://wiki.php.net/rfc/soft-deprecate-s=
leep-wakeup</a></div><div><br></div><div>Cheers,</div><div>Nicolas</div></d=
iv></blockquote><div><br></div>The PHP 8.5 RM team has discussed this inter=
nally, and arrived at the following. A full explanation of our reasoning fo=
llows.<br><br>- Given the accepted RFC for deprecating `__sleep()` and `__w=
akeup()` in PHP 8.5, we should aim to merge the deprecation in time for PHP=
 8.5, i.e. before PHP-8.5 is branched on September 23.<br>- If the RFC to s=
witch the deprecation to a &quot;soft deprecation&quot; is accepted, the RM=
 team is comfortable with landing a revert of the deprecation as long as th=
e revert can land before RC2.<br><br>Our reasoning is as follows (&quot;har=
d deprecation&quot; means the warnings, &quot;soft deprecation&quot; is jus=
t the documentation):<br><br>1. We cannot assume that the soft deprecation =
RFC will be accepted. However, if we wait until we know for certain that th=
e RFC fails, it would be too late to *then* merge the hard deprecation. By =
our math, if the soft deprecation RFC had exactly 2 weeks of discussion and=
 then 2 weeks of voting, the earliest it would close is October 4, with RC*=
2* being tagged October 7.<br><br>2. Since we cannot merge the hard depreca=
tion after RC1, the hard deprecation either needs to go into PHP 8.5 before=
 RC1, or be delayed until the next release. Since there was an RFC for doin=
g the deprecation in PHP 8.5 that got accepted, 8.5 should be preferred.<br=
><br>3. Having a hard deprecation in PHP 8.5, and converting it to a soft d=
eprecation in PHP 8.6 (or PHP 9.0, whatever is next), does not make sense. =
For the soft deprecation RFC to be meaningful, we would need to not have th=
e hard deprecation warnings in PHP 8.5.<br><br>4. If the hard deprecation i=
s implemented for 8.5 (per note 2) but the soft deprecation RFC is accepted=
, then (per note 3) we should remove the hard deprecation warnings from PHP=
 8.5. However, such a relatively large change should not be made too close =
to the GA release of PHP 8.5.0. Release candidates are meant to match the e=
ventual release as closely as possible.<br><br>5. Given the minimum schedul=
e outlined in note 1 above, there are a few days before the soft deprecatio=
n RFC could finish voting and when RC2 is packaged. This should be enough t=
ime to land a revert of the hard deprecation, given that a) the patch can b=
e reviewed and approved before the RFC finishes, and b) the patch is likely=
 to be just a revert of the original deprecation patches. By removing the w=
arnings from RC2, community developers waiting to test the release candidat=
es until after the warnings were removed can have 3 release candidates to d=
o so.<br></div></div></blockquote><div><br></div><div>The interesting thing=
 with that approach is that all libs that do test with=C2=A0php-src dev-mas=
ter will see the deprecation, so at least some OSS maintainers will work on=
 addressing=C2=A0this as we speak.</div><div>This might give useful hints a=
bout the impact of the deprecation (like the feedback from Sebastian on php=
unit, followed by one from Thomas stating this resulted in a perf issue).</=
div><div>On Symfony, we have 3 branches maintained: the next major is alrea=
dy free from sleep/wakeup; the next minor has BC layers that look like the =
ones presented in the RFC; and the next patch-level is not free from the de=
precation: we addressed throwing/internal/final cases and chose the option =
to silence in the CI instead for the complex cases. The CI is still not gre=
en: dependencies will have to be patched also. I&#39;ve no idea how much ti=
me this will take. But I know it&#39;s a significant effort - way more than=
 usual for a deprecation!</div><div><br></div><div>As a corollary=C2=A0to y=
our message, I&#39;m wondering what would be the earliest we could open the=
 vote?</div><div>Our policy=C2=A0on the topic says:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">There&#39;d be a minimum of 2 weeks betwee=
n when an RFC that touches the language is brought up on this list and when=
 it&#39;s voted on is required. Other RFCs might use a smaller timeframe, b=
ut it should be at least a week.</blockquote><div><br></div><div>Should it =
be one or two weeks?</div><div>The earlier the better for everyone I think =
(I don=E2=80=99t expect to convince Tim either way, so from my side that pa=
rt of the discussion is done.=C2=A0;) )</div><div><br></div><div>Cheers,</d=
iv><div>Nicolas</div></div></div>

--0000000000008a47df063e895be4--