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. Regards Anatol
