Re: We Want Quality

I have no problem with the notion of a feature freeze as soon as the RC is declared. That is not, however, what Sascha or Andrei were talking about. They were talking about a code freeze. De-facto, it just so happens that people find more bugs on one hand, and developers try to fix more bugs on the other hand, after an RC is announced. Code-freezing the RC means this is either not possible, or causes a fairly indefinite delay for the release. I'm not too concerned about stopping people from committing new features (something that can be done using branches, I guess). I simply don't see a better way of doing things than the way we're doing them today, as far as the release process is concerned (I'm not talking about QA of all sorts, which will be welcome if it shows up). Zeev On Thu, 29 Jun 2000 rubys@us.ibm.com wrote: > > > Zeev Suraski wrote: > > > > Considering branches don't work too nicely with CVS, halting > > development for long periods of time (1-2 weeks) would, > > de-facto, hurt the development of PHP. We should definitely > > implement a feature freeze, but a code freeze is simply not > > possible IMO. > > What problems do you see with branches in CVS? > > 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. > > - Sam Ruby > > -- Zeev Suraski <zeev@zend.com> http://www.zend.com/