Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98844
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <HE1PR02MB10521D9C0839BEA18F3B9B55BA1D0@HE1PR02MB1052.eurprd02.prod.outlook.com>
References: <CAESVnVoHZo2hRPKE+eC4zed85+g+MGE=yuDHPMTZrRD1vTaCFw@mail.gmail.com>
 <CAF+90c9oQMrtWCkb4anY5+eE-9wMQNZC-30kqE10MOmP+2zPWA@mail.gmail.com> <HE1PR02MB10521D9C0839BEA18F3B9B55BA1D0@HE1PR02MB1052.eurprd02.prod.outlook.com>
Date: Sat, 22 Apr 2017 13:49:07 +0200
Message-ID: <CAF+90c_p2Lw8+2ii43oMFGUTCE12x-O+ndc4WYRz9HXGFYX4qw@mail.gmail.com>
To: Anatol Belski <ab@php.net>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141c2da31a6d5054dbff6cf
Subject: Re: [PHP-DEV] [7.2] Timetable
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1141c2da31a6d5054dbff6cf
Content-Type: text/plain; charset=UTF-8

On Sat, Apr 22, 2017 at 1:09 PM, Anatol Belski <ab@php.net> wrote:

> Hi Nikita,
>
> > -----Original Message-----
> > From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> > Sent: Thursday, April 20, 2017 7:06 PM
> > To: Sara Golemon <pollita@php.net>
> > Cc: PHP internals <internals@lists.php.net>
> > Subject: Re: [PHP-DEV] [7.2] Timetable
> >
> > On Thu, Apr 20, 2017 at 6:43 PM, Sara Golemon <pollita@php.net> wrote:
> >
> > > My how time flies!  Feature Freeze for PHP-7.2 is coming up in exactly
> > > THREE MONTHS on July 20th.  Get your RFCs discussed, voted on, and
> > > implemented unless you want to wait for PHP-7.3
> > >
> > > -Sara
> > >
> > > Ref: https://wiki.php.net/todo/php72#timetable
> > >
> >
> > I've been wondering for some time why we have the beta + RC split, where
> RCs
> > are treated in essentially the same way as betas. In particular our
> minor version
> > RCs (as opposed to patch RCs) are *not* candidates for release. Might it
> make
> > sense to move RC1-5 to Beta 4-9 and keep only one scheduled RC?
> >
> Yeah, it's a bit unusual, as many projects usually have all the way
> alpha/beta and then one or max two RCs. On the other hand, a paradox fact
> is, that the QA participation on beta is far lower, at least from what I
> could tell from the past. Maybe that's just due to the naming, so people
> decide not to bother testing early stages and wait for something more
> substantial, I can only guess at here. On the other hand, nothing prevents
> RMs to switch back to beta, if there are some hard weight issues
> discovered, thus reflecting the dev state. Maybe there was some other
> reasons, why it was initially done this way, though.
>
> > Similarly, does it really make sense to have a new pre-release every two
> weeks?
> > I know that "we've always done it this way", but I'm not sure I see the
> > motivation behind it (or who the target audience for a biweekly release
> is).
> >
> From my experience, it is a very helpful approach. A pre release in this
> case is a kind of a buffer we have, to ensure the previous development
> didn't cause follow up issues. It could be illustrated by this primitive
> time lines
>
> ---> development ----------------> patch X reverted ---------> further
> development
> --------------> snapshot RC ------> patch X reverted in RC ---------->
> final based on RC
>
> In many cases this approach helps to catch one or another issue, so it's
> not included into the final patch version.
>
> Regarding the target audience, I can tell that the RCs are tested by Remi
> Collet on Fedora, by the OSTC team on Windows and some other third parties.
> It is useful also to ask some particular reporter to test the RC to ensure
> the exact fix will be contained in the GA release. Fe in some case, a buggy
> patch can still stay in the dev and be fixed, but excluded from the release
> and tested in the subsequent RC. In some case, there theoretically could be
> even RC2 for a patch version. I had never to do that, but basically that's
> an option if some very bad road blocks would appear in RC1. For the
> stability this approach is suitable quite well, as for me.
>

To clarify, I wasn't referring to our patch release RCs here, I certainly
see the usefulness of those. What I had in mind is that the current release
timeline for PHP 7.2 plans one new release (alpha, beta or RC) *every two
weeks* starting June 8th and continuing for 12 releases. This seems
excessive and I don't think there are many people who are interested in
testing a new release every two weeks. At least after the alpha phase the
PHP-7.2 branch should be about as low-activity as our other release
branches (as all features have landed by this time), so there will not be a
lot of changes between releases two weeks apart. This fast-paced release
cycle is probably also part of the reason why we have to do the beta/RC
switch early, as it's pretty hard to take a "beta 9" seriously, it's just
"yet another beta" at that point.

I don't think we'd lose much (actually I suspect that reducing the number
of releases will increase willingness to test them) if we used a monthly
release cycle instead (e.g. using 2 alphas, 2 betas and 2 RCs.)

Nikita

--001a1141c2da31a6d5054dbff6cf--