Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97073
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: Kalle Sommer Nielsen <kalle@php.net>
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com>
 <7604bd74-bfd7-fe3b-a9b2-4717187b6c52@gmx.de>
 <CAJW__o1_95DOM1HzrSXT3Kkra6Oi0dLtP9nX=YCvwPbLvTXepw@mail.gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>,
 Internals <internals@lists.php.net>
Message-ID: <9dca9031-577f-697c-844e-031247c2cc66@gmx.de>
Date: Sat, 19 Nov 2016 19:56:15 +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: <CAJW__o1_95DOM1HzrSXT3Kkra6Oi0dLtP9nX=YCvwPbLvTXepw@mail.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")

Hi Kalle!

On 19.11.2016 at 19:35, Kalle Sommer Nielsen wrote:

> 2016-11-19 19:23 GMT+01:00 Christoph M. Becker <cmbecker69@gmx.de>:
>
>> IMHO, we should consider introducing a fixed schedule for major releases
>> (say, every 4 years).
> 
> I think that should depend on a case by case basis for when we are
> working towards a new version, a lot of awesome work are already in
> for master that won't be out for at least another year. At the point
> when we pick RMs for the next branch, then we have in the past
> evaluated the scope of changes currently planned to be included, what
> is currently in and what the magical guys at Zend are doing and decide
> there. Having a fixed, forced major version does not sound that great
> if we do not have something awesome that could only ever exist in a
> new major version,

But this short-dated decision on whether next will be a major or minor
is exactly the problem.  Consider, for instance, this RFC which targets
7.2 for deprecation and 8.0 for removal.  What if we decide in some
month that there'll be no 7.2, but rather 8.0 will be next?  Would we
remove the features without a deprecation phase, or would we deprecate
them for 8.0 and remove later?  Either way, I'm pretty sure that we
would have a lenghty discussion, and might even need another vote.  And
at least some RFCs and documentation would have to be fixed.

At the very least I would suggest to decide whether the next version but
one will be major or minor at the same time we tag the first alpha of
the next version.  I.e. this decision would had been made months ago,
and actually all RFCs I've read assume that PHP 7.2 will be next.

-- 
Christoph M. Becker