As I recall the 7.1.0 release process there was never a time when a scheduled release didn't have enough changes to warrant it.
I think consistently scheduled releases give us a few things: - Early access to changes as they progress - Predictable timelines - No rush to get a bunch of things in because the next one is only two weeks away Additionally, the value of the multiple RCs is that it gives a nice runway between when breaking changes and new RFCs are allowed in and shoring up implementations for the release. Ideally, you'd have more Alphas than Betas, and more Betas and than RCs, but the reality is that until you freeze for RC, the dust doesn't settle. I think the current release schedule (or similar) has produced good results, and see no reason to change it unless we change some of the semantics. E.g. more Alphas, but no more RFCs after Beta 1, but you're just shifting the process down the line a bit, it's just names at that point. - Davey On Sat, Apr 22, 2017 at 2:05 PM, Anatol Belski <a...@php.net> wrote: > > > > -----Original Message----- > > From: Nikita Popov [mailto:nikita....@gmail.com] > > Sent: Saturday, April 22, 2017 1:49 PM > > To: Anatol Belski <a...@php.net> > > Cc: Sara Golemon <poll...@php.net>; PHP internals < > internals@lists.php.net> > > Subject: Re: [PHP-DEV] [7.2] Timetable > > > > 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.) > > > Ah, I understood it in wrong direction then. For the minor pre cycle, > probably some release could be omitted, if there's no activity, like we > currently do with a security branch. AFAIR there was no case like that with > 7.0, but that's also clear why as it was a major change. Probably would be > good to hear more impressions from RMs about how it went with other > branches. The timeline is anyway just a planning, it could be good that > some beta could replace the planned RC, if there are some issues. Depending > on impressions others have, probably the process could be indeed slackened > a bit, needing an RFC and extension to the release process doc. Maybe it > could be enough to have a release monthly, or more frequent if some urgent > fixes are to be tested, with the distance of two weeks as minimum. > > Not the last factor here is, I can tell, is also that the new RMs have > more practice on the actual release process. There are several nuances that > are better to be practiced before it comes to GA. > > Regards > > Anatol >
