Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103444
MIME-Version: 1.0
References: <CAF+90c8itae3inWZ8W-1GSGFH7W03bzHuOOimkUjbEPMqTEVww@mail.gmail.com>
 <091debad-319d-7010-4852-fb9d7e6304ac@gmx.de> <CAJHtznxd7XoLH02a4Y4f5vfEbJX7GoJiwXtdGWpVSOkcXNTS9g@mail.gmail.com>
 <CAESVnVpSkjcpVGaCYrXeTHiHqTAoWEe+rxBZnpX+mRzYG2Ce2A@mail.gmail.com>
In-Reply-To: <CAESVnVpSkjcpVGaCYrXeTHiHqTAoWEe+rxBZnpX+mRzYG2Ce2A@mail.gmail.com>
Date: Thu, 15 Nov 2018 20:24:45 +0100
Message-ID: <CAF+90c_WX8YiL-xHT3_S1HUjQtaP8BbDChZbmF-3V1gJpk9ZDQ@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: zeev@php.net, Christoph Becker <cmbecker69@gmx.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000eeea7c057ab901bf"
Subject: Re: [PHP-DEV] Re: Branch off PHP-7.4 early
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000eeea7c057ab901bf
Content-Type: text/plain; charset="UTF-8"

On Thu, Nov 15, 2018 at 7:46 PM Sara Golemon <pollita@php.net> wrote:

> 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
>

I'm not sure how we got to 7.4 becoming a feature branch. The options as I
see it are:

1) Fork PHP-7.4, make master PHP 8 and merge all commits up to master.
Likely means that many commits that could target 7.4 will be going into
master, because we really can't be bothered.
2) Keep PHP 7.4 on master and feature branch PHP-8.0-Preview, without
merging every commit. Everything that's not PHP 8 specific continues to
land on master and targets PHP 7.4.

Both are sensible options, it depends on whether we want to focus
development on PHP 8.0 (first option) or PHP 7.4 (second option) at this
point in time. My vote goes to 2) for now. We should have a place for PHP 8
changes now, but with the release still being at least two years away I
don't think it should become our primary development branch just yet.

Nikita

--000000000000eeea7c057ab901bf--