geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Where did the 1.1 branch go?!?!
Date Fri, 16 Jun 2006 03:11:42 GMT
On 6/15/06, Alan D. Cabrera <list@toolazydogs.com> wrote:
> David Blevins wrote:
> >
> > Then you both missed the beginning of this thread where Aaron was
> > saying "i want to update branches/1.1 with a fix for 1.1.1, where did
> > it go?"  The issue is, we haven't released 1.1 yet and no one should
> > be updating that source till then.
> >
> > Hence the idea to copy 1.1 aside as 1.1.0 so the activities of
> > creating, voting, and shipping 1.1 (which take about a week) could
> > happen in parallel to bug fixing 1.1.1.
>
> That sounds really dangerous to me.
>
> We're adding fixes to a release that hasn't gone out yet?

I think smaller project that have smaller volumes of bug fixes and
faster release cycles can afford to freeze even new bug fixes to bug
fix branch to get the release done.  And so what your saying would
make sense for projects like that.

It seems that since geronimo is continually getting bug fixes etc,
and the release process is not a few hour thing, it actually makes
sense to create a 1.1.0 branch to cut the release since that branch
would be the one that's frozen and not the 1.1 branch which can
continue to receive bug fixes.

Even for ActiveMQ I may switch to this model when doing releases.
Right now when I do releases, all the build process changes (switching
from 4.0-SNAPSHOT to 4.0), is all done in my working copy and that is
not checked into svn.  I do the build and if looks good, I cp my
working copy to the 4.0 tag.  This works for activemq since the build
and release process is simple, but when ever I need to recut the 4.0
tag it gets more complicated and it would have been easier if I would
have created a 4.0.0 release branch to begin with.

So +1 for the release manager creating the x.y.z branch at release
time to allow them to freeze changes and update the build and go
through a few release cycles.

-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message