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
