# [RFC] Deprecations for PHP 8.0 - Thread: https://externals.io/message/110383 - Original archive: https://news-web.php.net/php.internals/110383 - Started by Nikita Popov on 2020-06-05T09:04:41+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #110383 — Nikita Popov — 2020-06-05T09:04:41+00:00 URL: https://externals.io/message/110383#110383 Hi internals, It's that time of year again. Feature freeze is looming, so it's time to talk about deprecations! https://wiki.php.net/rfc/deprecations_php_8_0 The procedure is as usual. There are multiple deprecations part of the RFC, but they will be voted separately. If you would like to add something to the list, please try to provide an extended rationale (but I reserve the right to not include it, if I consider it too controversial.) I'm also happy to remove deprecations or adjust their scope, if there are good arguments for doing that. Consider this more as a point to start discussion than a finalized proposal. Regards, Nikita --- ## #110384 — Nicolas Grekas — 2020-06-05T09:14:37+00:00 URL: https://externals.io/message/110383#110384 · In reply to: #110383 > It's that time of year again. Feature freeze is looming, so it's time to > talk about deprecations! > > https://wiki.php.net/rfc/deprecations_php_8_0 > Thanks for the RFC. Would it make sense for you to postpone this for 8.1? I'm talking with my experience on Symfony here: we decided to give ppl some rest when they upgrade and always have our *.0 versions deprecations-free. Chasing BC breaks is a hard enough task for ppl to upgrade. Adding the additional step of solving deprecations is extra work that is not needed yet. I know solving deprecations is optional, but many teams have CI that fail on deprecations. I think it could be nicer to the userland community to have a smother path here, IMHO. Nicolas --- ## #110385 — Nikita Popov — 2020-06-05T09:24:43+00:00 URL: https://externals.io/message/110383#110385 · In reply to: #110384 On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas wrote: > > It's that time of year again. Feature freeze is looming, so it's time to > > […] > > Thanks for the RFC. > Would it make sense for you to postpone this for 8.1? > I'm talking with my experience on Symfony here: we decided to give ppl > some rest when they upgrade and always have our *.0 versions > deprecations-free. > Chasing BC breaks is a hard enough task for ppl to upgrade. Adding the > additional step of solving deprecations is extra work that is not needed > yet. I know solving deprecations is optional, but many teams have CI that > fail on deprecations. > > I think it could be nicer to the userland community to have a smother path > here, IMHO. > > Nicolas > Hey Nicolas, I'm certainly open to that! I don't think there's any strong reason to deprecate any of these in PHP 8.0 in particular, as we'll only be able to drop them in PHP 9.0 anyway. Anyone else have thoughts on that? We do already have a couple of deprecation in PHP 8.0, but those are generally directly related to some change that happened in PHP 8.0 in particular. Regards, Nikita --- ## #110404 — Theodore Brown — 2020-06-07T02:58:27+00:00 URL: https://externals.io/message/110383#110404 · In reply to: #110385 > On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas > wrote: > > > […] > > Hey Nicolas, > > I'm certainly open to that! I don't think there's any strong reason to > deprecate any of these in PHP 8.0 in particular, as we'll only be able to > drop them in PHP 9.0 anyway. Anyone else have thoughts on that? > > We do already have a couple of deprecation in PHP 8.0, but those are > generally directly related to some change that happened in PHP 8.0 in > particular. Because I follow the internals mailing list and RFCs closely, I don't personally feel too strongly about which version the deprecations are in, since regardless I can make sure my own code doesn't use these features. But for the large body of PHP devs that don't follow internals, wouldn't they want to be notified sooner if something will be deprecated? Waiting almost feels like keeping the planned deprecations a secret from outside developers, resulting in more code being written using these features in the meantime, and when they are finally deprecated the migration ends up being more work than it otherwise would be. So while I understand the desire to make upgrades as easy as possible, I'm not convinced it's a good idea to delay these deprecations for a later release. At the very least if deprecation is likely the PHP manual should say something about it. Best regards, Theodore --- ## #110405 — Kalle Sommer Nielsen — 2020-06-07T04:46:27+00:00 URL: https://externals.io/message/110383#110405 · In reply to: #110404 Den søn. 7. jun. 2020 kl. 05.58 skrev Theodore Brown : > So while I understand the desire to make upgrades as easy as possible, > I'm not convinced it's a good idea to delay these deprecations for > a later release. At the very least if deprecation is likely the PHP > manual should say something about it. I agree with this and feel very strongly about it, we should not delay deprecations since they can be disabled on a configuration level by removing the `E_DEPRECATED` bits from error_reporting anyway. Allowing our users to know at the earliest possible moment when something is going to be deprecated allows userland to have a larger time for upgrading as these warnings about certain behavior will change many years from now, but old behavior is still in effect. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #110406 — Deleu — 2020-06-07T09:18:24+00:00 URL: https://externals.io/message/110383#110406 · In reply to: #110405 What if Nikita changes the RFC to target PHP 8.1 but proceed with voting now? If voting passes, the RFC will be pending implementation and the "news" will start to spread. Brandt will write about it in his blog, Reddit will have a post about it, etc. and the community will start to spread the information. Maybe even include 3-way voting and let people decide which version to target. I'm still on the fence whether I like or dislike depredations coming on 8.1, but my guess is that by carring on with the RFC now the information will be spread and people will know about it. > Den søn. 7. jun. 2020 kl. 05.58 skrev Theodore Brown < > theodorejb@outlook.com>: > > […] > > I agree with this and feel very strongly about it, we should not delay > deprecations since they can be disabled on a configuration level by > removing the `E_DEPRECATED` bits from error_reporting anyway. Allowing > our users to know at the earliest possible moment when something is > going to be deprecated allows userland to have a larger time for > upgrading as these warnings about certain behavior will change many > years from now, but old behavior is still in effect. > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net --- ## #110407 — Kalle Sommer Nielsen — 2020-06-07T10:34:14+00:00 URL: https://externals.io/message/110383#110407 · In reply to: #110406 Den søn. 7. jun. 2020 kl. 12.18 skrev Deleu : > > What if Nikita changes the RFC to target PHP 8.1 but proceed with voting > now? If voting passes, the RFC will be pending implementation and the > "news" will start to spread. Brandt will write about it in his blog, Reddit > will have a post about it, etc. and the community will start to spread the > information. > Maybe even include 3-way voting and let people decide which version to > target. > > I'm still on the fence whether I like or dislike depredations coming on > 8.1, but my guess is that by carring on with the RFC now the information > will be spread and people will know about it. The question is, why is it important to delay deprecations when they can safely be ignored, functionality will remain the same anyway so it is only a problem for those whose development environments enable `E_DEPRECATED` in error_reporting. If Symfony (or any other project for the matter) wants to to have no deprecation warnings but cannot make the date for PHP 8.0.0's release, then they shouldn't target PHP8 and we should not delay our process due to that. Either way the changes proposed by this RFC is relatively small and the potential candidate that could hold some projects back (which I hope not), is the accessing static members on traits part, but likely minimal. By the time 8.1.0 is on the horizon, the list of potential deprecations could have doubled. It is important to have php.net be the source of truth for everything, so the official word on deprecations should come in the form of the documentation at php.net and the warnings emitted from php-src. We should not rely on others posting about these deprecations before they happen, everything and nothing can change in between now and when it is eventually implemented. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #111068 — Nikita Popov — 2020-07-17T10:12:19+00:00 URL: https://externals.io/message/110383#111068 · In reply to: #110384 On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas wrote: > > It's that time of year again. Feature freeze is looming, so it's time to > > […] > > Thanks for the RFC. > Would it make sense for you to postpone this for 8.1? > I'm talking with my experience on Symfony here: we decided to give ppl > some rest when they upgrade and always have our *.0 versions > deprecations-free. > Chasing BC breaks is a hard enough task for ppl to upgrade. Adding the > additional step of solving deprecations is extra work that is not needed > yet. I know solving deprecations is optional, but many teams have CI that > fail on deprecations. > > I think it could be nicer to the userland community to have a smother path > here, IMHO. > > Nicolas > I've retargeted this RFC to PHP 8.1 now. These deprecations are not time-critical, there has been little discussion of the deprecations themselves, and we're already in feature freeze induced RFC overload... Nikita