[boost] Re: 1.32 release preparation

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-28 06:25:19

"Robert Ramey" <ramey_at_[hidden]> writes:

> Dave Abrahams wrote:
>
>>I'd like to know the reasons for "all the sudden rush".  We did
>>announce a schedule long ago, and it has already been delayed by three
>>weeks.  I'm not asking in order to point fingers; I just want to know
>>how to avoid the "sudden rush" next time.
>
> Here is the current scenario. 
>
> a) The announcement gets posted - release 1.32 scheduled for date x.
> b) Each developer decides - uh oh I better get in my changes before date x.
> c) Of course these changes take longer
> d) and break some other things
> e) which takes longer still
>
> Personally I think the concept of scheduling a release fundamentally
> flawed.

We have a book deadline and we need to have a CD go out with the book,
and the CD needs to contain a new boost release.  So schedules are, at
least occasionally, a fact of life.

> I would suggest another idea.

> a) the release manager or the core influential developers keep an eye on the
> current state of the CVS tree and tests.  
> b) When things look "pretty good", branch for release without warning.  None
> of this loading my latest feature in to make the schedule.

What if things don't ever look "pretty good" without intervention?

> c) the Main tree goes on as usual
> d) pending issues in the release branch are addressed by nagging the person
> responsible.
> e) the new version is releases with a number like 1.31.1 

How is that a change from what we're doing?

> or maybe even 28 July 2004.
> f) any changes between branch and release should be just bug fixes which can
> then be merged back into the development tree.

Experience shows that merging in the other direction tends to be
safer and more productive.

> Under this system, releases would occur more frequently - on the order of 6
> weeks.  If you're ready to check in your latest feature and the new release
> branch catches you with your pants down - well too bad. But it's no big deal
> because the next release will be in 6? weeks anyhow which is close to what
> its going to take to shake out the repercussions of your check in anyway.

This reminds me of recent suggestions I've heard that new C++
standards could be released on a 6-month timetable.  I think you'd
feel differently if you had ever managed a release.

> I realize that this is not the most orthodox way of doing things.  But I
> think it's really hard to get such a large number of people working
> independently on exactly the same schedule.

You have a point.  I have some trouble with details of your
suggestion, but I think it has merits, too.

Also, without a release deadline, would accepted libraries *ever* get
checked in? ;-)

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com