Hi
On 5/11/23 00:10, Máté Kocsis wrote:
If not, then we could just move really slowly on deprecating them. We
could deprecate them at some point in the 9.x release cycle and remove
them in 10.0.
Although I would love to get rid of as many overloaded signatures as
possible due to the above mentioned fact,
I admit that there might be some signatures which other internals would
prefer to phase out slower than me. So
thanks for the idea! Now, the individual votes in the RFC contain 2 options
for removing a signature: a shorter path (deprecation
in PHP 8.4, removal in PHP 9.0) and a longer one (deprecation in PHP 9.0
and removal in PHP 10.0).
I believe this vote format ("three options") is not really compatible
with the voting rules (https://wiki.php.net/rfc/voting).
For example it's not entirely clear what would happen here:
5 votes to deprecate in 8.3 / remove 9.0
4 votes to deprecate in 9.0 / remove 10.0
4 votes to not deprecate.
Neither option has a 2/3 majority over any other option. The two
deprecation options together have a 2/3 majority over not deprecating,
which might indicate that a deprecation should happen. But in which
version? This would likely require ranked choice voting which feels
complex for something that should be a simple vote.
I've had a similar issue with my "Improve unserialize() error handling
RFC" (https://externals.io/message/118566) and opted to make an
executive decision as the RFC author and not offer one of the possible
version targets to avoid that problem entirely.
----------------------
Repeating my previous question:
Does it necessarily follow that a function that is deprecated in major X
must be removed in major X+1? Otherwise deprecating with 8.3 and
removing in 10 would be an option that could be evaluated when it's time
for 9 and the migration did not yet "sufficiently" happen in userland code.
Would it be an option to just deprecate everything in PHP 8.3 and defer
the vote for the removal target version to a later date? This would give
users the deprecation notice as early as possible and also gives them
appropriate time to migrate if migration for a specific set of functions
is (much) slower than others. 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.
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
