Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
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 >> 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 > 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
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
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. On Sun, Jun 7, 2020, 06:46 Kalle Sommer Nielsen wrote: > Den søn. 7. jun. 2020 kl. 05.58 skrev Theodore Brown < > theodor...@outlook.com>: > > 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 > ka...@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
On Fri, June 5, 2020 at 4:24 AM Nikita Popov wrote: > 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 > >> 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. > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
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 >> 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 > 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
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
> 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
