Re: Re: Branch off PHP-7.4 early
| From: | Nikita Popov | Date: | Mon, 28 Jan 2019 09:27:37 +0000 |
| Subject: | Re: Re: Branch off PHP-7.4 early | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-103861@lists.php.net to get a copy of this message | ||
On Thu, Jan 24, 2019 at 5:11 PM Levi Morrison <levim@php.net> wrote:
> On Thu, Jan 24, 2019 at 7:52 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
> >
> > On Fri, Nov 16, 2018 at 4:36 PM Sara Golemon <pollita@php.net> wrote:
> >
> > > On Fri, Nov 16, 2018 at 9:26 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > > > I feel like there may be some understanding here, because what
> > > > is proposed here seems to match exactly what you proposed
> > > > in your first mail to this thread.
> > > >
> > > Perhaps the impedance mismatch is in calling the branch "PHP-8".
> > > Calling it that says to me, "It's my responsibility to merge bugfixes
> > > if I want them propagated to what will become 8.0.0-final". Calling
> > > it "feature/jit-and-other-cool-stuff" or literally ANYTHING other than
> > > "8" says, "Development is happening as normal, and the feature branch
> > > is the problem of the people working on the feature.
> > >
> > > Also, I'm going to quote again the specific language Dmitry used:
> > >
> > > > - 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).
> > > >
> > > "move" says to me "rename the branches", which again, if fixes
> > > aren't
> > > being dutifully picked/merged/whatever to this branch, then they
> > > inevitably will get lost. It's not that I don't trust someone working
> > > on the feature branch to do their best, it's that it shouldn't be
> > > their responsibility.
> > >
> > > -Sara
> > >
> >
> > I'd like to bring this up again. Typed properties has been merged, so we
> > currently don't have any major code changes pending. To clarify what
> > exactly I'm proposing:
> >
> > * Create the PHP-7.4 branch now/soon, rather than in summer.
> > * master will be PHP 8.0.
> > * All changes are applied to the lowest applicable branch and then
> merged
> > up as usual, including to PHP-7.4 and master.
> > * NEWS mentions for bug fixes are only added up to PHP-7.3. They are not
> > added on the PHP-7.4 branch, just like for master. (Excluding changes
> that
> > are only in 7.4/8.0, of course.)
> > * All feature additions can generally still go to the PHP-7.4 branch,
> > there is no freeze.
> > * Backwards incompatible changes and major internal API changes can go
> to
> > master (assuming they are accepted through the usual processes).
> >
> > Nikita
>
> As long as someone will help me get the covariance/contravariance
> patch merged in correctly when the time comes, I'm all for it.
>
As the reception seems positive, I'll go ahead and create the branch now.
Nikita