Re: We Want Quality

Unless I'm missing something, doing that comes to solve the inability to go on adding features after an RC has been announced. While that's a Good Thing, that doesn't solve our issue, which is fixing bugs during the RC period, which could in theory trigger new bugs. Considering how things work in the PHP project nowadays I'm still in favour of fixing bugs during the RC period, doing our best not to mess anything up, even if the price is a messup every once in a while. Otherwise, bugs would simply not be solved. Zeev On Thu, 29 Jun 2000 rubys@us.ibm.com wrote: > > > >> One thing I did with the 3.1 release of jakarta-tomcat was to create a > >> branch for the release, and allowed mainline development to continue > >> unimpeded on the main branch. Those that wished for a particular fix to > >> go into the release had to take an explicit, overt action. > > > >This isn't a bad idea. My problems with branches in the past have always > >been with respect to merging branches. If you branch without ever needing > >to merge the changes back into the main branch it would probably be > >ok. However, people would then have to remember to commit their fixes to > >both branches. > > It also uses branches the opposite of the way they normally are used - but > then again, I've never been strong on conformity. ;-) > > The trick to making this work is being serious about release candidates > being release candidates, not merely betas. By this I mean a release where > one does not expect changes. Part of this is educating people that the > next release isn't the last release - there always is going to be another > one. > > But what really makes it work is that it isn't the default action. So, in > practice I've found that the number of changes made falls off dramatically. > Yes, in theory, a small percentage of the small number of changes may not > make it into the next release - but typically you have multiple weeks to > catch that problem. > > In general, QA-type people team tend to love the approach (after all, it is > hard to certify a moving target). And the development team certainly likes > it much better than extended freezes... > > I suggest that PHP give it a try at least once... > > - Sam Ruby > > -- Zeev Suraski <zeev@zend.com> http://www.zend.com/