Giovanni Bajo writes:

Aleksey Gurtovoy wrote:

...

I'd like to test the waters for the last week of June -- let's say Monday, June 28 -- being the target date for the next major release, which I am volunteering to manage. Correspondingly, June 21 or so would be a branch-for-release date, by which everything should be in CVS and in the releasable shape.

I think we should try and allow a larger period of time to fix the regression tests.

It's definitely going to be more than one week, and the above wasn't meant to suggest otherwise (note "the releasable shape"). I did imply a different branch creation pattern than you suggest below, though.

I suggest we branch for instance 1 month before the release, and then we restrict the branch only to the patches which stabilize the regression tests (no new features allowed there). Plus, the trunk is free for new features, and development is not stalled.

Early branching would definitely give us more freedom for main trunk evolvement, and might even improve our release cycle in terms of predictability (although it's been my impression that in past almost all destabilizing checkins were due to "judgment errors" rather than accidental mistakes). On the other hand, any major development should be led in a separate branch anyway, so stalling is more a theoretical problem, IMO. The downside of branching early, is, of course, that the developers making fixes would have to do more work incorporating those both in the branch and the main trunk. I guess it's worth trying. What do others think? -- Aleksey Gurtovoy MetaCommunications Engineering