geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: [VOTE] Release branching process (was Re: Life After 1.1 - starting the new branch for 1.1.1 - some logistics and your input requested.)
Date Thu, 22 Jun 2006 04:38:25 GMT
David,

Thanks for that excellent recap.

+1 from me.

+1 to Alan's comment that all patches to branches should also be
applied to the trunk.  Any future x.(y+1) branch should come from the
trunk and not from the recently frozen x.y.z branch.


Cheers
Prasad

On 6/21/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> +1
>
> On 6/21/06, Alan D. Cabrera <list@toolazydogs.com> wrote:
> > +1
> >
> > I think that we should mention that patches that go into
> >
> > x.y.z also go into x.y and trunk
> > x.y also go into trunk
> >
> > Last time we neglected to apply patches evenly across the board when
> > fixes were checked into one branch.  This is one reason why the versions
> > drifted so wildly apart.
> >
> > Regards,
> > Alan
> >
> > David Blevins wrote:
> > > We had this whole conversation last week, lots of good discussion was
> > > had.  I'd prefer not to have to have it again.  Here is my exact
> > > understanding of our consensus and would like to put it to a vote to
> > > avoid reinterpretation of that consensus in the future.
> > >
> > > 1.   branches/x.y would be the branch for all x.y.z releases
> > >
> > > 2.   when a release is frozen, we spin off a branch with that *exact*
> > >      name, as in branches/x.y.z, where z starts at zero and increments
> > >      by one.
> > >
> > > 3.   at that time branches/x.y is immediately updated to version
> > >      x.y.(z+1)-SNAPSHOT
> > >
> > > 3.   We cut releases from the frozen branch
> > >
> > > 4.   When a release passes final tck testing and final vote, the
> > >      frozen branch is moved to tags
> > >
> > > We create a branch at freeze time for the following reasons:
> > >
> > > 1.  it takes *at least* one week from freeze to ship due to voting,
> > >     tck testing and potential repeats of that process (re-cut,
> > >     re-certify, re-vote).  There is no reason why work on x.y.z+1
> > >     needs to be delayed -- only 52 weeks a year.
> > >
> > > 2.  stronger guarantee no one is updating the branch once frozen
> > >
> > > 3.  less likely that people and ci systems (continuum) will checkout
> > >     and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
> > >     would need to be removed manually and may accidentally be
> > >     distributed.
> > >
> > > 4.  it is currently very difficult to roll version numbers forward,
> > >     entries here and there are often missed.  Far better to have
> > >     branches/x.y have a few straggling old x.y.z-SNAPSHOT versions
> > >     than a few overlooked x.y.z final numbers that needed to go back
> > >     to SNAPSHOT -- they never leave SNAPSHOT and need to be reverted
> > >     back later if that process happens in the frozen branch.
> > >
> > >
> > > Here is my +1
> > >
> > >
> > > -- David
> > >
> > >
> > >
> > > 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