On Mon, Sep 8, 2025 at 8:21 PM Nicolas Grekas <[email protected]>
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 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

Reply via email to