Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <3dd3fe15-5797-f450-62b2-37cc154b03f7@gmx.de>
In-Reply-To: <3dd3fe15-5797-f450-62b2-37cc154b03f7@gmx.de>
Date: Mon, 25 Jun 2018 18:03:00 +0300
Message-ID: <CAJHtznx_VZxXNn8Efk1-pOUYn6zy4eBK_JiQPOpzR23bf8i_Bw@mail.gmail.com>
To: cmbecker69@gmx.de
Cc: Zeev Suraski <zeev@zend.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000002b2df8056f78aec6"
Subject: Re: [PHP-DEV] Re: PHP 2^3
From: vsuraski@gmail.com (Zeev Suraski)

--0000000000002b2df8056f78aec6
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 25, 2018 at 5:57 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 25.06.2018 at 14:30, Zeev Suraski wrote:
>
> > What this list is - a collection of directions around which we've
> performed varying amounts of research (some of them quite a lot, like JIT),
> that I think is strong grounds for us to start discussing a PHP 8 timeline,
> and making PHP 7.3 the last feature release in the PHP 7.x family.  If we
> had to come up with an educated guess as to when PHP 8 could be ready to be
> released based on the abovementioned featureset, we're probably talking
> about 2-2.5yrs away (i.e. mid/late 2020).  We can also consider having a
> very slim PHP 7.4 release sometime in 2019 that wouldn't add any
> functionality, but that would give us an opportunity to deprecate anything
> that we missed in 7.3 that truly requires deprecation - while still
> allowing folks to prepare for 8.0 ahead of time.
>
> Why not stick with our yearly release cycle, and ship 7.4.0 in Dec 2019
> and 8.0.0 in Dec 2020?
>

We could and I think we should, but I don't think 7.4 should be a feature
release - but rather another release where we can deprecate things without
rushing them into 7.3, and at the same time provide people with a smoother
upgrade path to 8.0 (even though as you know, I'm not the biggest fan of
compatibility breakages...).  We've never been successful at working on two
active-development branches at the same time, and with the resource levels
we have - I don't think it's practical.

To be perfectly honest, I don't think our userbase for the most part is
actually consuming the feature releases at nearly the frequency that we're
producing them.  It's a healthy release cycle, but I really don't think
that there would be any meaningful downside to have two years between the
last feature-release 7.x and 8.0.

Zeev

--0000000000002b2df8056f78aec6--