Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103441
MIME-Version: 1.0
References: <CAF+90c8itae3inWZ8W-1GSGFH7W03bzHuOOimkUjbEPMqTEVww@mail.gmail.com>
 <091debad-319d-7010-4852-fb9d7e6304ac@gmx.de> <CAJHtznxd7XoLH02a4Y4f5vfEbJX7GoJiwXtdGWpVSOkcXNTS9g@mail.gmail.com>
 <CAF+90c8UG4Y1XuAe__mN6tTBq-zxuoYT3bLdr3nhSTk4GOPOXQ@mail.gmail.com>
In-Reply-To: <CAF+90c8UG4Y1XuAe__mN6tTBq-zxuoYT3bLdr3nhSTk4GOPOXQ@mail.gmail.com>
Date: Thu, 15 Nov 2018 10:54:27 -0700
Message-ID: <CAFMT4Np4YRS2Nkrv1B+z+3_qDEAbxFt1sYxXM=2tqMLeYJ9kaw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: zeev@php.net, Christoph Becker <cmbecker69@gmx.de>, internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: Branch off PHP-7.4 early
From: levim@php.net (Levi Morrison)

On Thu, Nov 15, 2018 at 9:59 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> On Thu, Nov 15, 2018 at 5:46 PM Zeev Suraski <zeev@php.net> wrote:
>
> >
> >
> > On Thu, Nov 15, 2018 at 5:07 PM Christoph M. Becker <cmbecker69@gmx.de>
> > wrote:
> >
> >> On 15.11.2018 at 15:27, Nikita Popov wrote:
> >>
> >> > Based on previous discussions, it appears that our current plan is to
> >> > release PHP 8.0 after PHP 7.4. Normally we only branch off versions once
> >> > they reach beta stage, which means the PHP-7.4 branch will only be
> >> created
> >> > around summer 2019.
> >> >
> >> > I would like to propose to branch off PHP-7.4 earlier this time and
> >> start
> >> > working on PHP 8.0 in the master branch. This will allow people to start
> >> > working on changes that are not suitable for PHP 7.4 (due to either
> >> > significant internal ABI breakage, or userland breakage).
> >> >
> >> > Because each new branch introduces a lot of merge overhead for
> >> > contributors, I would further propose that merges should only go up to
> >> > PHP-7.4, while merges into master (PHP 8) will be performed
> >> occasionally,
> >> > on an as-needed basis, by the people working on it.
> >>
> >> Have you considered having a separate PHP-8 branch, which can be rebased
> >> onto master from time to time, and eventually be merged into master
> >> (basically, treating the PHP-8 branch as a big feature branch)?
> >>
> >
> > 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.
> >
> > 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.
> >
>
> If people are introducing major changes (e.g. when typed properties lands)
> it's reasonable to expect that they will also carry out the merge to the
> PHP 8 branch, as such merges are often tricky and require domain knowledge.
> What I'm mainly suggesting is that we do not merge every single commit into
> the PHP 8 branch, as is our current practice. Depending on where you land
> your change, you currently already have to merge across PHP-7.1, PHP-7.2,
> PHP-7.3 and master, which is a pretty big hassle. I would rather not add
> one more branch to that list.
>
> I really don't think that merging into the PHP 8 branch is going to be an
> issue, though we can always reconsider the merge procedure if that turns
> out to be wrong.
>
> 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.
> >
>
> For me PHP 7.4 is more important for deprecations than typed properties. If
> we don't have a PHP 7.4 release, we end up in the same situation as PHP 7:
> We have an opportunity to introduce a degree of BC breakage, but the last
> opportunity to introduce deprecations has already sailed by the time the
> decision is made. Unless we are fine with removing functionality without
> prior deprecation, I think we need the PHP 7.4 release.
>
> Nikita

I strongly agree on 7.4 being necessary.

I think no matter how we do the branching we will have some headache;
I will support whatever the most active committers and maintainers
decide is best.