Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97065
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.22 as permitted sender)
To: Rowan Collins <rowan.collins@gmail.com>, internals@lists.php.net
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com>
Message-ID: <7604bd74-bfd7-fe3b-a9b2-4717187b6c52@gmx.de>
Date: Sat, 19 Nov 2016 19:23:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 19.11.2016 at 18:23, Rowan Collins wrote:

> 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?

IMHO, we should consider introducing a fixed schedule for major releases
(say, every 4 years).

-- 
Christoph M. Becker