On 10/29/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote: > > > I think I prefer Richard's suggestion of not branching until we're > > ready to make the .0 release. The effect should be the same except > > that people don't have to deal with checking patches in on the branch > > vs. the trunk until after 4.3.0 goes out. > > This would certainly make things easier. And easier is fine by me... > > Jason, any thoughts on how to translate "ready to make a .0 release" > into "made a .0 release," in terms of a firm schedule, with dates? I'm > assuming that the < 100 bugzilla count is an adequate milestone for the > release branch to be cut. > > Or do you think < 100 implies branch implies 4.3.0 release, as > originally described by Richard is the way to go? > > I'm willing to try this. It's just that I would like some advance notice > before a release, just to check over things. (Say, a week. Maybe two. It > doesn't have to be a long time. And it should definitely not stretch > to 1 or 7 months...)
Sure. I'd expect the usual release candidate or two separated by one or two weeks. I'd also expect the mainline to be frozen after rc1. I guess branching can happen at the point there is either rc2 or the 4.3.0 release. > Just curious. I think we all agree on the general goal of a rapid and > timely release once the branch is cut. It's the specific details that > I'm curious to learn... We'll all learn as this would be the first time we do it this way ;) Richard.
