On 10/04/2023 18:17, Pierre Joye wrote:
I understand agency work, managers pushing new features instead of a
cleaning some legacy.
however years of ignoring deprecation notices (very few were introduced
right before 8.0).
Most of them could have been fixed within a couple of hours in any code
base, if they had tests.
I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.
We're NOT asking PHP to freeze!
We're asking for proper analysis of the effects of these changes on end
users, and proper consideration of the time that it will take for
end-users to upgrade... and the answer to that is NOT "within a couple
of hours". Call it unnecesary overhead if you will, but many tech teams
have process flows for their work that don't simply entail "run rector
on your codebase and deploy". Even just the admin overheads of raising a
ticket for the change, creating a Merge Request, Peer Review, etc can
take a few hours of time in many teams. And that's before making the
assumption that all older code has a good test suite, and CI pipeline...
if it has, then it's probably code that's being updated regularly
anyway, by developers that do try to keep everything up-to-date.
Nor are end-user developers the only people that are affected. End-user
developers typically have the luxury of writing their code for a single
version of PHP, so upgrading the version is a step from one version to
the next. Library writers don't have that luxury: their codebase
normally has to work with a range of PHP versions including the latest
release; and any fixes that are made for the latest release still have
to work with older PHP versions, which can take significantly more
effort to maintain.
--
Mark Baker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
