Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102482
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.18 as permitted sender)
To: Jakub Zelenka <bukka@php.net>, Zeev Suraski <vsuraski@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals list <internals@lists.php.net>
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <3dd3fe15-5797-f450-62b2-37cc154b03f7@gmx.de>
 <CAJHtznx_VZxXNn8Efk1-pOUYn6zy4eBK_JiQPOpzR23bf8i_Bw@mail.gmail.com>
 <CAEKnhAFvzYdZV2+92pScq30SB_ebhE-o+uEuFx=Fhr6vObOm6w@mail.gmail.com>
Message-ID: <e38597dd-135e-5bd7-e6bd-7bb98b42c3e8@gmx.de>
Date: Wed, 27 Jun 2018 15:10:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAEKnhAFvzYdZV2+92pScq30SB_ebhE-o+uEuFx=Fhr6vObOm6w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: PHP 2^3
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 27.06.2018 at 15:00, Jakub Zelenka wrote:

> I think it makes sense for big engine changes that you described but I
> don't think this should be the case for features in core extensions and
> SAPI's. The thing is that some of us are not going to work on those big
> changes for various reasons. Personally I work mainly on fpm, openssl as
> well as some other stuff and just don't have time to do anything else atm.
> My features are not really so big that they should wait 2 years. The thing
> is that this type of changes won't usually conflict with engine changes so
> there should be no reason to delay it.
> 
> So I think it would be good idea to lock the engine (possibly create a
> special branch for all the new changes into it) and release 7.4 and maybe
> 7.5 (in case 8.0 is not ready in time) with just deprecations and features
> in extensions and SAPI's.

This was my first thought as well, but considering the changes that PHP
7 required for *all* extensions, working on 7.4 and 8.0 simultaneously
may easily lead to hard to resolve merge conflicts, and even to subtle
breakages.

However, instead of locking 7.4 for everything but deprecations in
advance, we may consider to decide on a case-by-case basis if a new
feature should target 7.4 or 8.0.

-- 
Christoph M. Becker