On Fri, May 12, 2023, at 9:59 PM, Rowan Tommins wrote: > On 12 May 2023 19:17:20 BST, "Máté Kocsis" <kocsismat...@gmail.com> wrote: >>Libraries have to >>get rid of deprecated calls in any case, otherwise >>their users will surely start to complain. > > I've said it before, and I'll say it again: the solution to this is not > fewer deprecation messages; it's better documentation to stop people > confusing deprecations for errors, and better functionality for users > to choose which messages they see.
A better argument, I think: The old function exists in 8.2, the new one does not. The new one exists in 8.3. The old one ceases to exist in 9.0. That means it's impossible to write code that works from 8.2 to 9.0 without version checks. The overlap period is only 2 releases (8.3 and 8.4). That's too short of a window. That's mitigated by these all being very uncommon cases, yes, but as a principle we should give people more warning than that. I am actually tempted to propose that we do deprecations at the very start of a release, 9.0 and 9.1 only, and then not allow them for the rest of that major, for that exact reason. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
