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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
