Hi Daniel, Thanks for the update.
Le lun. 8 sept. 2025 à 19:25, Daniel Scherzer <daniel.e.scher...@gmail.com> a écrit : > On Mon, Sep 8, 2025 at 8:21 PM Nicolas Grekas < > nicolas.grekas+...@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 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. > 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 week. Should it be one or two weeks? The earlier the better for everyone I think (I don’t expect to convince Tim either way, so from my side that part of the discussion is done. ;) ) Cheers, Nicolas
