Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128659
Precedence: list
MIME-Version: 1.0
References: <CAOWwgpk1Z_bns=Z55TqpYOBXvBGpurMfjTGPSgQ6Uf5QXfLOjg@mail.gmail.com>
In-Reply-To: <CAOWwgpk1Z_bns=Z55TqpYOBXvBGpurMfjTGPSgQ6Uf5QXfLOjg@mail.gmail.com>
Date: Mon, 8 Sep 2025 20:25:09 +0300
Message-ID: <CALaXqqRBRJdMO0Jvguj57M5U2nTVn_3DK6bB433RBmWvHuA-wA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000040009f063e4d7a94"
From: daniel.e.scherzer@gmail.com (Daniel Scherzer)

--00000000000040009f063e4d7a94
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 8, 2025 at 8:21=E2=80=AFPM Nicolas Grekas <nicolas.grekas+php@g=
mail.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 t=
o
> 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 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.

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 until
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 sense.
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. Release
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, community
developers waiting to test the release candidates until after the warnings
were removed can have 3 release candidates to do so.

Thanks,
--Daniel Scherzer, Volker Dusch, and Pierrick Charron

--00000000000040009f063e4d7a94
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Sep 8, 2025 at 8:21=E2=80=AFPM Ni=
colas Grekas &lt;<a href=3D"mailto:nicolas.grekas%2Bphp@gmail.com">nicolas.=
grekas+php@gmail.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_qu=
ote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>Hello internals,</div><div><br></div><div>Following the discu=
ssion that started at <a href=3D"https://externals.io/message/128226#128456=
" target=3D"_blank">https://externals.io/message/128226#128456</a> I wrote =
this RFC to formalize our consensus=C2=A0on the topic.</div><div><br></div>=
<div>TL;DR, this is about converting the deprecation of __sleep and __wakeu=
p to a documentation-based soft deprecation:</div><div><a href=3D"https://w=
iki.php.net/rfc/soft-deprecate-sleep-wakeup" target=3D"_blank">https://wiki=
.php.net/rfc/soft-deprecate-sleep-wakeup</a></div><div><br></div><div>Cheer=
s,</div><div>Nicolas</div></div></blockquote><div><br></div>The PHP 8.5 RM =
team has discussed this internally, and arrived at the following. A full ex=
planation of our reasoning follows.<br><br>- Given the accepted RFC for dep=
recating `__sleep()` and `__wakeup()` in PHP 8.5, we should aim to merge th=
e deprecation in time for PHP 8.5, i.e. before PHP-8.5 is branched on Septe=
mber 23.<br>- If the RFC to switch the deprecation to a &quot;soft deprecat=
ion&quot; is accepted, the RM team is comfortable with landing a revert of =
the deprecation as long as the revert can land before RC2.<br><br>Our reaso=
ning is as follows (&quot;hard deprecation&quot; means the warnings, &quot;=
soft deprecation&quot; is just the documentation):<br><br>1. We cannot assu=
me that the soft deprecation RFC will be accepted. However, if we wait unti=
l we know for certain that the RFC fails, it would be too late to *then* me=
rge the hard deprecation. By our math, if the soft deprecation RFC had exac=
tly 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 deprecation after RC1, the hard deprecation either ne=
eds to go into PHP 8.5 before RC1, or be delayed until the next release. Si=
nce there was an RFC for doing 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 deprecation 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 the hard deprecation warnings in PHP 8.5.<br><br=
>4. If the hard deprecation is implemented for 8.5 (per note 2) but the sof=
t 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 candid=
ates are meant to match the eventual release as closely as possible.<br><br=
>5. Given the minimum schedule outlined in note 1 above, there are a few da=
ys before the soft deprecation RFC could finish voting and when RC2 is pack=
aged. 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 finishe=
s, and b) the patch is likely to be just a revert of the original deprecati=
on patches. By removing the warnings from RC2, community developers waiting=
 to test the release candidates until after the warnings were removed can h=
ave 3 release candidates to do so.<br><br>Thanks,<br><div>--Daniel Scherzer=
, Volker Dusch, and Pierrick Charron=C2=A0</div></div></div>

--00000000000040009f063e4d7a94--