Re: [RFC] Deprecations for PHP 7.2
| From: | Rowan Collins | Date: | Sat, 19 Nov 2016 17:23:19 +0000 |
| Subject: | Re: [RFC] Deprecations for PHP 7.2 | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-97057@lists.php.net to get a copy of this message | ||
On 18/11/2016 14:55, Nikita Popov wrote:
Hi internals! I've submitted this RFC for PHP 7.1 previously, but didn't follow through due to time constraints. Now I'd like to propose an extended version for PHP 7.2 and vote on it sooner rather than later to avoid a repeat performance.Hi Nikita, I'm interested to see create_function() on this list, as one of my first contributions to the list was suggesting its deprecation, and I didn't feel there was sufficient consensus to go forward. Thread here: http://marc.info/?t=138178649200002&r=2&w=2 http://marc.info/?t=138178649200002&r=1&w=2 It's possible the intervening three years have changed things sufficiently to reconsider, though. On a broader note, I would like to restate my desire for some kind of road map or plan of roughly when 8.0 is expected, to inform decisions on things like this. Does "deprecate in 7.2" mean removal in 2 years time, or 5, or 10? Previously I've been answered with "the Big Feature of 8.0 will be JIT", but I am not a fan of tying the deprecation and feature policy to "whenever we happen to have a rewrite of the engine ready"; it muddles product branding with API versioning. If JIT isn't ready for 10 years, does that mean we have to wait 10 years to break BC? And if it's ready in 2018, does that mean everything deprecated in 7.2 has to be immediately dropped after just one year? Should we decouple the Zend Engine version from the language version, and use separate semantic versions for each? Regards, -- Rowan Collins [IMSoP]https://wiki.php.net/rfc/deprecations_php_7_2