Re: [boost] [1.36.0] Suggestions for 1.36.0

From: Richard Newman (richard_at_[hidden])
Date: 2008-03-28 10:48:42

First off, congratulations on your 1.35.0 R3 and near release.  It's a 
lot of work updating infrastructure and in the midst of it often thankless.

Beman Dawes wrote:

> Andrey Tcherepanov wrote:
>> Beman,
>>
>> May I humbly suggest "release more often" item as well? Say, as soon as 1  
>> or 2 new libraries are accepted, merged into release branch and it is  
>> stable? Or even  "try to release at least last-dot-bug-fix release every  
>> 2-4 months"?
> 
> Good points.
> 
> We are aiming for a quarterly release. 1.35.0 took five months, but our 
> infrastructure and procedures are improving, so I hope the next one can 
> be done in three months.

I'm questioning your point that 1.35.0 took 5 months.  1.34.1 was 
released on July 24, 2007, more than 8 months ago.  Does this mean you 
didn't "start" a release until 5 months ago?  Is the delay between 
finishing a release and starting the next one part of the issue in 
improving the frequency of releases?  Should the next release team be 
ready to go as part of the release process rather than as an afterglow 
activity?

> 
> We probably need to be a bit more specific about schedules. For example, 
> a twelve week schedule might look something like this:
> 
> * New libraries, major revisions of old libraries, and big 
> infrastructure changes need to be merged in the first three weeks.
> 
> * Minor fixes can be merged up until three weeks before the release 
> target date.
> 
> * Release candidate generation and review will begin three weeks before 
> the release target date.

As a "client" of the boost process, we'd probably upgrade once every 6 
months, but quarterly gives us a choice of two releases in that period. 
That choice would depend somewhat on perceived stability. For instance, 
under the present system, we tend to take the x.y.1 releases over the 
x.y.0 releases because we perceive the x.y.1 to be of higher 
reliability.  Longer than 6 months and we start pining away for the new 
libraries and improvements.

I'm good with the current paired release heartbeat of library/major 
additions (x.y.0) and maintenance/reliability improvements (x.y.1), but 
together each pair should occur at least semi-annually.  Quarterly 
releases can do this or some other heartbeat.  In principle, 
monthly/weekly/nightly releases are possible (if testing and building 
are sufficiently automated), but then certain ones become anointed as 
the "real" releases anyway.  Regardless, we'll just pick one of them 
every 6 months to actually deploy.

Richard Newman