[sldev][META] Release Candiate Cycles (was 1.18.2.1 source code)

Nicholaz Beresford nicholaz at blueflash.cc
Wed Sep 26 07:12:30 PDT 2007


Joshua Bell wrote:
> The down side is a potentially vicious circle: If it consistently takes 
> a long time to stabilize a release, the number of pending changes 
> waiting for the next release piles up. And the more changes that go into 
> a release, the longer it'll take to stabilize. Which can lead to a 
> temptation to take shortcuts around the process.

 From what I've seen with 18.3 RC I'd expect that the work (fixes) get
progressively less ... at least the source diffs between each of the
RC iterations were smaller and smaller.


> (I suspect that this is mitigated in either a smaller development team 
> or in the classic boxed-software waterfall development cycle - during 
> the stabilization phase, everyone is doing nothing but stabilization. In 
> our case, the incoming bug rate is low enough that most developers are 
> unblocked and continuing to work on other bugfix work or features. As 
> the user base increases this may change.)

How are you doing that practically?  I guess theoretically you'd merge
fixes into a 18.4 branch now and as soon as the RC goes gold, a new
18.4 RC should be waiting in the wings and an 18.5 ready to branch for
merging postponed fixes/patches?



Nick


More information about the SLDev mailing list