On 12/03/2022 15:23, Ilija Tovilo wrote:
You're absolutely right. I will attempt to gather some numbers. For option 3, I also think "not widely used" is just plain wrong. As for option 4, I'm fairly confident it only exists by accident 95% of the time.
Like Andreas, this is my biggest concern with the proposal: the lack of actual figures for how many libraries will be affected b the change. We've seen a lot of deprecations over the last year, and they always create some degree of pain for library/toolchain maintainers. While typically dismissed as "it's just a deprecation notice", and being accused of creating a "storm in a tea cup" whenever we raise questions, library maintainers are the ones who have to deal with the additional work when end users raise issues against their repos becase of all the notices they're nw seeing in their logs; who already have a lot of work preparing for each new release; who are expected to have fully eliminated any deprecations from their repos (or their dependencies) on or before the GA release date. How much extra work and/or stress is it going to give those who maintain the PHP ecosystem?
From the preparation work for the 8.0 release, there has barely been breathing space over the last two years; dealing with null arguments passed to internal functions, and other (not always docmented) changes, those libraries/tools take a lot of work to maintain. And with so many deprecations going into this release, I would like to see some risk assessment undertaken on the affect that each deprecation RFC will have, with some real figures for the number of repositories that require work to prepare them for the release.
-- Mark Baker _________ |. \ \-3 |_J_/ PHP | || | __ | || |m| |m| I LOVE PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
