geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Preparation for M4
Date Tue, 05 Jul 2005 02:15:34 GMT
On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote:
> David Blevins wrote:
> >On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote:
> >
> >>David Blevins wrote:
> >>
> >>>Anything I missed?
> >>>
> >>
> >>SNAPSHOT elimination so the build is reproducible.
> >
> >
> >Right.  Missed that one for M3 IIRC.
> >
> >
> >>Branch so that M4 can stabilize whilst other changes are being made.
> >
> >
> >We do for every milestone.  Don't expect this to be different.
> >
> >
> >>Acceptance test process - how do we know what works (need to avoid a 
> >>broken release like M3).
> >
> >
> >That's what I meant by:
> >
> >  DB> We have a number of people interested in testing.  I'll ping
> >  DB> them when I have something ready.
> >
> >Was thinking to branch when I dish out the binaries for testing.
> >Rather than the "surprise, here is a binary" approach we've done in
> >the past.  Sounds pretty much like what you are proposing as well.
> >
> 
> Yes - in the past we've just tagged and moved on. This time I think we 
> should create the branch at the start of the process rather than at the 
> end as there seem to be a lot of pent up changes planned. Yes, we may 
> need to merge some critical changes back to this branch but hopefully 
> this can be kept to a minimum.
> 
> So basically,
> * create a branch now, say 1.0-M4-prep
> * do the stuff we talking about now on that branch
> * cut the final M4 distro
> * drop the 1.0-M4-prep branch
> 
> Other work can continue on the trunk without destablizing the M4 release.
> 

+1 That's pretty much what I had in mind.


-David

Mime
View raw message