On Wed, 24 Sep 2003, Jeff Turner wrote: > On Wed, Sep 24, 2003 at 10:16:05AM -0400, Berin Loritsch wrote: > > Steven Noels wrote: > > > > >Carsten Ziegeler wrote: > > > > > >>With respect to the recent thread about release management, I propse > > >>a release date of October, 1th which would include a freeze of the > > >>cvs starting on monday, 29th. > > > > > > > > >+1 - let's do a serious freeze this time. > > > > > >>a) Make a 2.1.2 release on October, 1th > > > > > > > > >+1 > > +1 > > > Better yet: > > > > Since the process of code freezing is not encouraged, use labels. Start > > with the release candidate label first (i.e. marking it now before it > > changes). > > So that would be something like 2_1_2_RC, and if all is good, you can > > relabel > > that exact release 2_1_2_FINAL. > > We tried this in Forrest and found it didn't work very well. Unless a > freeze is declared, people will start committing stuff for the next > version. Any last-minute bugfixes for 2.1.2 will be mixed with changes > for 2.2, and there's no bugfix-only version of the file to update the tag > to. The status.xml file is guaranteed to exhibit this problem. The > Forrest 0.5 status.xml has some bogus 0.6 entries as testament to this ;P
IIHO the right way is using a branch not just tags. During the release period backport bug fixes to the other branch. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
