Re: [VOTE] Deprecations for PHP 8.1

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]