geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.
Date Wed, 21 Jun 2006 23:54:56 GMT
On 6/21/06, Jason Dillon <jason@planet57.com> wrote:
> Why would a "branch" get moved to a "tag"?  Why do we need branches
> for revisions?  Why are we deleting branches?
>
> IMO, we should have a branch for each Major.Minor, where all of the
> Major.Minor.Revision work happens.  So branches/1.1 would hold the
> active work for 1.1.x.  When it is time to make a release, then svn
> cp from branches/1.1 to tags/1.1.1, and then keep working on 1.1.2 on
> branches/1.1
>
> IMO, branches should never become tags.  Tags only get copied to new
> branches when we need to apply critical fix to a specific release,
> otherwise we should just roll up the change into the next release of
> the series.
>
> I recommend minimizing branching where possible, so I don't think
> that branches for 1.1.1 or 1.1.1.0 are a good idea.  SVN is not that
> good at merging, and making it simple (like Perforce), so lets try
> not to set ourselves up for icky merges by making branches for each
> release.

Hi Jason,

I agree that we should avoid branching.  But I do agree with the 1.1.1
branch.  It's a dead-end branch in that it's only used to prepare he
release.  Applying last minute fixes and changing version numbers.
Since it's a dead-end branch, once the release if approved
moving/deleting it makes sense.

>
> --jason
>
>
> On Jun 21, 2006, at 4:14 PM, Matt Hogstrom wrote:
>
> > After the branches/1.1 was moved to tags there was some question as
> > to what happened to the 1.1 branch.  At that time some kind soul
> > created a new branches/1.1.1.  No activity has occurred in that
> > branch and given that we'll need to define the release goals of
> > 1.1.1 soon I'd like to propose the following.
> >
> > After 1.1 is released:
> >
> > * Delete branches/1.1.1
> > * Move branches/1.1.0 to tags/1.1.0
> > * Copy tags/1.1.0 to branches/1.1.1
> > * Update branches 1.1.1 to be 1.1.1-SNAPSHOT
> > * Start working on 1.1.1
> >
> > When 1.1.1 enters time for release
> >
> > * Move branches/1.1.1 to branches/1.1.1.0
> > * Change version from 1.1.1-SNAPSHOT to 1.1.1
> > * Create release candidate rc1
> > * put out for a vote
> > * get a successful vote with no respins :)
> > * move from branches/1.1.1.0 to tags/1.1.1.0
> >
> > Based on all the confusion in the past I think this procedure makes
> > it clear what phase were in for the release as well as avoids
> > tagging and branching repeatedly.
> >
> > I'm looking for lazy consensus and not a formal vote.
> >
> > Matt
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message