On Sat, Apr 22, 2017 at 1:09 PM, Anatol Belski <a...@php.net> wrote: > Hi Nikita, > > > -----Original Message----- > > From: Nikita Popov [mailto:nikita....@gmail.com] > > Sent: Thursday, April 20, 2017 7:06 PM > > To: Sara Golemon <poll...@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 <poll...@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
