Den søn. 7. jun. 2020 kl. 12.18 skrev Deleu <deleu...@gmail.com>: > > 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
