On 08/07/2021 02:33, Mike Schinkel wrote:
What I was disagreeing with is your assertion that "by definition"
deprecation must be followed with near-term removal.
I think we're talking past each other, and actually mostly agree, but
are mixing up two questions:
a) Does deprecation always mean planned removal _at some point_?
b) *When* does that removal need to happen?
My intention all along was to answer question (a) - a deprecation notice
should imply that something will *eventually* be removed, not just that
it is "bad practice" to use it. That is a common definition, and I think
it's one that is useful to users.
What we mostly seem to be discussing is question (b), so, for the
record, here is what I think:
* Removal of a deprecated feature can be at any point in the future,
even the indefinite future, just not "never".
* Very short deprecation periods can be harmful, because they don't give
people enough time to change.
* Very long deprecation periods can also be harmful, because people will
put off making changes, and end up with a large back log when things are
finally removed.
* Specific plans are useful to users - "this will be removed in 2024" is
easy to base decisions on.
* Failing that, any plan is better than no plan at all - it's easier to
work with "a decision on this will be made in 2023 based on an estimate
of usage at that point" than "at some point between 1 and 100 years from
now, we'll remove it without further notice".
Regards,
--
Rowan Tommins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
