Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103446
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>
 <CAF+90c_WX8YiL-xHT3_S1HUjQtaP8BbDChZbmF-3V1gJpk9ZDQ@mail.gmail.com> <52d491a2-f546-f1eb-09e4-87f1b070d256@zend.com>
In-Reply-To: <52d491a2-f546-f1eb-09e4-87f1b070d256@zend.com>
Date: Fri, 16 Nov 2018 09:10:17 -0600
Message-ID: <CAESVnVrfq-Q-Ai_FrU3h3xvzpL70RbJ1qDJALu2vk1pSSa485w@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, zeev@php.net, 
	Christoph Becker <cmbecker69@gmx.de>, 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 Fri, Nov 16, 2018 at 7:17 AM Dmitry Stogov <dmitry@zend.com> wrote:
> - in the near future (by mid January) fork PHP-8 and start active
> development there. Keep PHP-7.4 development in master, and don't require
> committers to merge into PHP-8, but restrict PHP-7.4 for minor changes
> or features that won't significantly affect PHP-8 branch.
>
> - in May/June move master into PHP-7.4, make PHP-8 to be master and
> require committers to work on master and backport changes (according to
> usual PHP/GIT workflow).
>
If fixes are not required to be merged to PHP-8, then how do we ensure
that those fixes (especially the security ones) will still be in
effect when 8.0 is released?

> To target typed-properties or other significant changes to PHP-7.4, it's
> better to commit them before PHP-8 branching.
>
How will that impact deprecations?  Are we calling those "not
significant"?  I'd actually say yeah since they tend to take the form
of a few lines of "stop doing this".  I do worry about our ability to
pull a deprecations list together by January though.

FTR; This feels like the worst available option.  It's basically just
early branching with bad names.  I'd much sooner branch PHP-7.4 in
January and have that be it.

-Sara
On Fri, Nov 16, 2018 at 7:17 AM Dmitry Stogov <dmitry@zend.com> wrote:
>
>
> On 11/15/18 10:24 PM, Nikita Popov wrote:
> > 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.
>
> hi,
>
> After all, and despite of the first proposal was mine, now I think, we
> should start from the second option.
>
> - in the near future (by mid January) fork PHP-8 and start active
> development there. Keep PHP-7.4 development in master, and don't require
> committers to merge into PHP-8, but restrict PHP-7.4 for minor changes
> or features that won't significantly affect PHP-8 branch.
>
> - in May/June move master into PHP-7.4, make PHP-8 to be master and
> require committers to work on master and backport changes (according to
> usual PHP/GIT workflow).
>
> To target typed-properties or other significant changes to PHP-7.4, it's
> better to commit them before PHP-8 branching.
>
> Thanks. Dmitry.
>