From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-04-04 18:35:52
On Apr 4, 2005, at 4:13 PM, Fernando Cacciola wrote:
>
> "Peter Dimov" <pdimov_at_[hidden]> escribió en el mensaje
> news:004d01c53761$6413ecf0$6501a8c0_at_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