From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-04-04 16:13:44
"Peter Dimov" <pdimov_at_[hidden]> escribió en el mensaje
> Victor A. Wagner Jr. wrote:
>> At Friday 2005-04-01 15:17, you wrote:
>>> Here's my suggestion for a release schedule. We allow two weeks to
>>> get all of the new features and bug-fixes we want into CVS, but still
>>> try to
>>> keep things sane. Then we fix bugs on the CVS trunk for a week,
>>> branch and fix bugs for another week, and then release on May 1. So,
>>> the important dates are: April 15 (two weeks from today): feature-freeze
>>> on CVS trunk.
>>> April 22 (three weeks from today): branch for 1.33.0
>> I'll say this again.... if you branch, branch the development that's
>> NOT related to 1.33.0
> I'll agree again. The changes I check in when we are in release mode (have
> a release branch active) _always_ go to both the trunk and the branch. The
> branch doesn't help me in any way.
> Apr 15: feature freeze
> Release "when it's done"
FWIW, I agree.
In fact, it took some time to understand our current model becasue I had my
mind setup with release-THEN-branch.
I just couldn't get into the idea of working on something else than a
release (once the release is sheduled). Even in my own projects, I never
move past a release without finishing it first; so I couldn't understood why
was there an early branch. As Peter, I just have to _always_ propagate my
work into the Release branch simply becasue I wouldn't be working on
anything but the release until it's finish.
In the odd event that I have something terribly hot that I can't wait to
commit for a post-release version, I would just keep it in my disk.
Just my 2c
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk