On Tue, Jul 6, 2021 at 2:25 PM Jakob Givoni <ja...@givoni.dk> wrote: > On Tue, Jul 6, 2021 at 10:30 AM Rowan Tommins <rowan.coll...@gmail.com> > wrote: > > > > Hi Mike, > > > > > > > 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: > > > > > > > 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. > > > > I think it would be very helpful. > I would have loved to know that FILTER_SANITIZE_STRING was not > considered a good choice when I recently researched how to improve an > issue. > Deprecation without a fixed removal version is better than no > deprecation (because removal version was not agreed on). > > Actually I agree with everything that Mike said previously and I > strongly suggest a policy that looks like this: > > Deprecation means no longer encouraged (strongly) and might be removed > in a future (major) version. > Before every new major version, review all deprecated features/usages > and decide with a simple RFC if each of them should be removed, > reviewing the current usage level and migration paths. > > Best, > Jakob >
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. Regards, Nikita
