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
It's that time of year again. Feature freeze is looming, so it's time to
talk about deprecations!
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
On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:
It's that time of year again. Feature freeze is looming, so it's time to
talk about deprecations!
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
On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:It's that time of year again. Feature freeze is looming, so it's time to
talk about deprecations!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
Den søn. 7. jun. 2020 kl. 05.58 skrev Theodore Brown theodorejb@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
kalle@php.net
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>: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 theE_DEPRECATEDbits 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
Den søn. 7. jun. 2020 kl. 12.18 skrev Deleu deleugyn@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
kalle@php.net
On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas nicolas.grekas+php@gmail.com
wrote:
It's that time of year again. Feature freeze is looming, so it's time to
talk about deprecations!
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