> De : Rowan Collins [mailto:rowan.coll...@gmail.com] > > I think there should be a quick RFC collecting this reasoning, and a > formal invitation for contrary opinions, to avoid accusations that it > was slipped in the back door. If there really is no opposition, the RFC > will record that the vote was unanimous, and be a point of reference to > anyone looking for more explanation than the manual provides.
Quick or not, even deprecations requires an RFC and a formal vote, unless a special rule is written somewhere. And the RFC must clearly describe and plan the next step, because deprecation is temporary. I asked for an additional delay for 7.0 feature freeze and it was clearly rejected. So, IMO, even deprecation cannot go to 7.0. The best we can do is to deprecate in 7.1 and remove in 8.0, and I'll oppose any attempt to introduce exceptions in 7.0 (just because it would mean that the rules are not the same for everyone). For those claiming that it is 'merely a deprecation', that it won't 'break anything', and that ' people will have plenty of time to gracefully migrate their codebases', please remember that the coercive STH RFC was rejected mainly because some deprecations were considered as unacceptable BC breaks. So, there's no more permissive rules for deprecations. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
