Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103443
MIME-Version: 1.0
References: <CAF+90c8itae3inWZ8W-1GSGFH7W03bzHuOOimkUjbEPMqTEVww@mail.gmail.com>
 <091debad-319d-7010-4852-fb9d7e6304ac@gmx.de> <CAJHtznxd7XoLH02a4Y4f5vfEbJX7GoJiwXtdGWpVSOkcXNTS9g@mail.gmail.com>
In-Reply-To: <CAJHtznxd7XoLH02a4Y4f5vfEbJX7GoJiwXtdGWpVSOkcXNTS9g@mail.gmail.com>
Date: Thu, 15 Nov 2018 12:46:22 -0600
Message-ID: <CAESVnVpSkjcpVGaCYrXeTHiHqTAoWEe+rxBZnpX+mRzYG2Ce2A@mail.gmail.com>
To: zeev@php.net
Cc: Christoph Becker <cmbecker69@gmx.de>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: Branch off PHP-7.4 early
From: pollita@php.net (Sara Golemon)

On Thu, Nov 15, 2018 at 10:46 AM Zeev Suraski <zeev@php.net> wrote:
> First, I think that continuously merging the level of changes we have in
> store for PHP 8 on an ongoing basis from a branch into master - while
> master is a moving target - would be a pretty big headache.   That's why I
> think there's sense to PHP 8 being the master branch, where most
> development would go towards.
>
Okay, that's a fair argument against the feature branch route.

> However, I think that if PHP 8 is on master - it should become the
> responsibility of people who introduce patches for 7.4 - to also ensure
> that they work with 8 (master).  If PHP 8 will be in a branch, that's much
> less likely to happen.  Given the complexity and effort of 8, I think we
> could use some shared responsibility here, instead of putting the burden on
> the few working on the PHP 8 magic.
>
Yes to shared responsibility, no to failing to merge changes to 7.4 up
to master.  Either we will want that change, in case it should be
merged immediately rather than kicking the can down the road, or it
does not belong on master and we should null-merge it like we would
any other bugfix today.  We must not put ourselves in the position of
7.4 being ahead of master. Period.

> Another option, by the way, would be ditching 7.4 altogether and focusing
> our efforts on 8.0 right away.  It does mean people won't get typed
> properties in 2019, but it will mean they'll likely get PHP 8 sooner.
>
As tempting as that may be, I think this would be incredibly
irresponsible to PHP users.  7.4 is a necessity on the grounds of
having a deprecations release alone, nevermind the availability of new
features.

TLDR;
I'm willing to embrace an early fork for 7.4, but we treat it like a
normal fork, not a special-psuedo-feature-branch. I also strongly
oppose dropping 7.4 as a release.

-Sara