Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102485
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.169 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <e38597dd-135e-5bd7-e6bd-7bb98b42c3e8@gmx.de>
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> <e38597dd-135e-5bd7-e6bd-7bb98b42c3e8@gmx.de>
Date: Wed, 27 Jun 2018 14:54:47 +0100
Message-ID: <CAEKnhAE+REYNnxiz-4gW-j8evm8hoR7OgA5=qi2gcEm_SAS3dQ@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Zeev Suraski <vsuraski@gmail.com>, Zeev Suraski <zeev@zend.com>, 
	PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002f175e056f9ff5f7"
Subject: Re: [PHP-DEV] Re: PHP 2^3
From: bukka@php.net (Jakub Zelenka)

--0000000000002f175e056f9ff5f7
Content-Type: text/plain; charset="UTF-8"

On Wed, Jun 27, 2018 at 2:10 PM, Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> 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.
>
>
Well it was mainly about changing the zval but I guess it won't be the same
for 8.0 unless there are some plans for big breaking changes. It would
probably make sense to reconsider in that case but if the ABI stays the
same or the changes are minimal, then it shouldn't block new features to
the extensions IMO. In terms of SAPI's like FPM, it's a bit different as it
is mostly independent code and most of the features can be released without
any conflict even if the engine ABI changes considerably.

Cheers

Jakub

--0000000000002f175e056f9ff5f7--