Hi
On 5/11/23 18:58, Dan Ackroyd wrote:
On Thu, 11 May 2023 at 10:36, Tim Düsterhus <t...@bastelstu.be> wrote:
Would it be an option to just deprecate everything in PHP 8.3
As I said before, having at least one version where the new versions
of the functions are available, and the old versions aren't giving
deprecation notices, is the 'cleanest' way of refactoring functions.
Right. Replace "8.3" by "the first version after the replacement is
available" in my previous email. My main question was …
Deprecation notices only deliver their value when the old versions of
the functions are removed, and before then are a cost.
It doesn't really feel right to decide on
a deprecation for 9.0 / removal for 10.0 at the current time, but
deprecation in 8.3 + removal when it's ready seems to be okay.
I think I don't understand your concern.
If a problem is discovered with a planned removal of something, people
on this project are mostly reasonable*, and a small RFC to adjust to
the new circumstances would be very likely to pass.
… the following: I wanted to know if
"Deprecate in 8.x + not remove in 9.0, but only remove in 10.x or 11.x"
would be an option, because I feel that it is more useful than
"If we deprecate in 8.x then we MUST remove in 9.0, that's why we're
already making deprecation plans for 9.x, so we are able to remove in 10.0"
All the discussion so far had "Deprecate in x.y and remove in x+1.0",
but not "Deprecate in x.y and remove in x+n.0 with n > 1".
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
