Replying to Rowan and commenting on Nikita's message. > On Jul 6, 2021, at 4:24 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > >> Instead I replied because your email strongly implied (stated?) that >> "deprecation required removal" > > I stand by that interpretation, which while not universal is very widely > used, and I think is more useful than a general hint at "bad practice". > > You spend most of your e-mail seeming to argue against it, and then seem to > say that actually you do agree with it after all, and all you're saying is > that sometimes the deprecation period should be longer:
What I was disagreeing with is your assertion that "by definition" deprecation must be followed with near-term removal. > I am not advocating that. I am advocating we should consider making it: >> >> "features that are strongly discouraged will*probably* be removed in the >> next major version, but in some cases may be retained for one or more major >> versions." > > I'm totally OK with that. > > I do think that there should be a clear *plan* for removing each deprecated > feature, though. That plan might be "deprecate in 8.1, and examine prior to > 9.0 whether usage has dropped / the alternatives are mature / etc". It might > flat out be "deprecate in 8.1, but don't remove until 10.0". > > Otherwise, the message becomes "this feature is kind of bad, and at some > point we might decide to drop it without further notice, but actually we > might not, so no hurry to remove it", which I just think isn't that helpful. The "plan" that makes the most sense is one that takes into consideration the BC breakage that would occur at the time of removal, and that is not something you can project _in advance_. IMO you cannot really know in advance how long a feature might continue to be used in the wild in some cases, you can only evaluate the current situation when the time comes. Or as they say "no battle plan survives first contact with the enemy" and "facts on the ground matter." > On Jul 6, 2021, at 9:30 AM, Nikita Popov <nikita....@gmail.com> wrote: > > As far as this RFC is concerned (and this is the customary phrasing for all > deprecation RFCs), all changes are for deprecation in PHP 8.1 and removal > in PHP 9.0. That's the baseline. > > However, nothing prevents you from starting an RFC prior to the PHP 9.0 > release that counters the prior decision and extends the deprecation period > for another major version. However, the onus is now on you to argue that > something previously deprecated should not be removed (or not be removed > yet). If you cannot make a strong argument for that, then the default > action is taken. > > We do still carry a couple deprecations from PHP 5 times around, because > actually removing the affected functionality has some technical issues. And this is exactly how it should be. That deprecating a feature w/o near-term removal is a legitimate approach to have people vote on. IOW, that deprecation does not "by definition" require near-term removal. Removal is determined when appropriate and by vote, and not any hard-and-fast "IF deprecated THEN must be removed soon." Please note that I am fully respecting the ballot and voting outcomes here; if people always vote to remove a deprecated feature in next major version that so be it. But RFC authors should be allowed to propose a long time horizon for removal without being told they "are doing it wrong." -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
