cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: Freeze policy? (was Re: [Vote] Releasing next version)
Date Thu, 25 Sep 2003 08:50:57 GMT
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


Mime
View raw message