Santiago Gala wrote: > El mié, 21-02-2007 a las 07:39 -0800, David Sean Taylor escribió: >> I would like to propose an official release date of version 1.0.1 as >> February 27, 2007 (Tuesday) >> I would also like to propose that all feature work complete by today, >> and that only documentation and bug fix work continues thru Monday >> night. >> > > I read recently that it does not make sense to cut a release *after* > voting it. Actually, the process they do in httpd and a few other > projects is more like a two phase commit: > > - vote a (fuzzy) calendar > - feature freeze, alpha-N or rc-N releases > - once one of the rc-N releases reveals as good enough, it is voted and > becomes the version > > The advantages of this strategy is that the committers vote on a > concrete tarball, with all its bugs and, in theory, no surprises. As > only very minor fixes are allowed between rc-N and rc-N+1, it would be > difficult to introduce heavy bugs in the "final" code. > > As Roy put it, it only makes sense to vote on concrete code, not on > "intentions to do". > > So I'd say, start feature freeze whenever, and repeat a vote when one of > the rc or snapshots seem to be ready to be released. > Yes, this is more or less a requirement for releases at Apache. The vote has to be done on a concrete tarball. So this means whenever you're ready prepare the tarball (including tagging etc) and vote on it. If for any reason the vote fails, this means increasing the version number! So if you prepare a 1.0.1 release, the vote fails, the next official release will be 1.0.2 to avoid confusion. There was an interesting thread recently on the jackrabitt developer list about this topic.
Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
