Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97057
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.174 as permitted sender)
To: internals@lists.php.net
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
Message-ID: <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com>
Date: Sat, 19 Nov 2016 17:23:19 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2
From: rowan.collins@gmail.com (Rowan Collins)

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.
>
>      https://wiki.php.net/rfc/deprecations_php_7_2
>

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]