On Apr 4, 2005, at 4:13 PM, Fernando Cacciola wrote:
"Peter Dimov" <pdimov@mmltd.net> escribió en el mensaje news:004d01c53761$6413ecf0$6501a8c0@pdimov2...
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.
Doesn't that assume that the work required for release is something that you're interested in? I'll provide a contrarian example. In the run-up to Boost 1.32.0, I'd finished all that I wanted to do with the Graph library and had stabilized it well before other libraries were ready (e.g., MPL, 'cause they had just finished their book). But, I had lots more that needed to go into the Graph library so that our work could continue. For me, the release branch happened too late, and I ended up creating the graph_devel_1_33_0 branch for everything that would go into 1.33.0 after 1.32.0 had branched. It was also a pain, just like checking into a release branch. Earlier branches and late branches all have benefits and problems. Only shortening the time between freeze and branch solves them. Doug