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?!?! - Summary and recommendation
Date Fri, 16 Jun 2006 16:53:52 GMT
On 6/16/06, Matt Hogstrom <matt@hogstrom.org> wrote:
> Here is what I got from the thread and think makes a lot of sense.
>
> Working copies of versions in branches would be branches/n.n.  This would be the effective
trunk for
> any version work.
>
> When the team has decided that work is done and the release process begins the branches/n.n
would be
> *copied* to branches/n.n.0 and the release work would be completed there.
>
> At the time of the copy two changes would occur:
>
> 1. In branches/n.n.0 the version number would be changed from n.n-SNAPSHOT to n.n.
>
> 2. In branches/n.n the version number would be changed to n.n.n-SNAPSHOT.  The plugin
numbers would
> be increased.
>
> The new branches/n.n would then allow people to work on the next set of changes (ostensibly
bug fixes).
>
> The release manager would maintain responsibility for branches/n.n.0.
>
> After the release is voted and approved the branches/n.n.0 would be moved to tags/n.n.0.
>
> I would expect that it is totally acceptable to build the final release from branches/n.n.0
and not
> have to rebuild once its has been moved to tags/n.n.0 as tags/n.n.0 is branches/n.n.0
and has simply
> been moved.
>
> I think this is the summary of the discussion and based on having released Geronimo twice
this is
> way better than what we are doing now.
>
> The remaining question is when a release is being completed off of trunk.  When this
occurs do we
> make a branches/n.n *AND* a branches/n.n.0 at the same time and apply versions n.n.n-SNAPSHOT
and
> n.n respectively?

I think that this need to stay flexible on this one.  We have to
remember that your cutting the x.y branch only because you don't want
to hold folks back from doing commit that should make it into the next
x.y+1 release.

So I could see a case where the n.y branch is cut weeks or months
before the finally release process kicks in which causes the x.y.0
branch to be created.  It could be you have several committers working
on new features aimed at the x.y+1 branch but the x.y still need to go
though a few weeks of bug fixing before you start the release process.

>
> Not trying to be nitpicky but its going to happen and since we're on the subject we can
close the
> loop here.
>
> After people's comments we can take a vote if we think we need one and I'll update the
release
> management section in our wiki with this information so the next set of people on the
project will
> have it at their disposal.
>
> Aaron Mulder wrote:
> > Now we only have a 1.0 branch and a dead-1.2 branch?  What's going on?
> >
> > Thanks,
> >    Aaron
> >
> >
> >
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message