Re: We Want Quality

>> 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