Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115371
To: php internals <internals@lists.php.net>
References: <CAF+90c96J7dyq1KsgoPTndM09V=oj46cXm0SxjfkJXiL3TjdHg@mail.gmail.com>
 <CACwt+JfrMa3h2GfG0cxNFmJeg3mPDzf6QWV44zuz+xYBqUsJfg@mail.gmail.com>
 <1dcefcec-a3e4-e773-4950-b11d377ecc7f@gmail.com>
 <122F660D-DE94-4DFE-A0E9-FEC202E89E3A@newclarity.net>
 <62eb8eff-e671-5b3b-5e25-2a5b38160fcd@gmail.com>
 <D85C91B1-7BFD-4DDD-ABAF-F9604529D7EB@newclarity.net>
 <586591d0-8bbc-a42c-f92b-819b8fc6ac20@gmail.com>
 <CAJmjfvXjQu-n699DkQWwBzRBdm3hjosz6o0Cxwy5AntFOua17A@mail.gmail.com>
 <CAF+90c-T0AgThGz5KX8ngv4e4To+cpuJ9vkXTfs8OAngUnO5ew@mail.gmail.com>
 <2E4D2A97-6E63-4161-ACB1-CA762AFDAD76@newclarity.net>
Message-ID: <4d45f558-b6e5-ef05-76c2-288e73739a5c@gmail.com>
Date: Thu, 8 Jul 2021 18:26:20 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <2E4D2A97-6E63-4161-ACB1-CA762AFDAD76@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
From: rowan.collins@gmail.com (Rowan Tommins)

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]