I'm not a big fan of performing development on a branch that, IMO,
should be frozen for QA. I'm not sure if that's what people are
proposing but, I just wanted to say that.
Regards,
Alan
On 7/4/2005 7:46 PM, David Blevins wrote:
Do we have a consensus that we should branch at the beginning of the release
cycle instead of at the end as we have done in the past?
If so, going to put out an email titled "M4 - 24 hour notice of branch", which
I think would be a good release practice.
-David
On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote:
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
