[boost] Release procedure. Where do we go?

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2007-09-03 06:55:01

Hopefully I am not seen as trying to add fuel to the fire, but I am 
wondering if anyone tried to perform an analysis of what exactly did not 
work with the (previous) release procedure.

I have seen David Abrahams trying to analyze the current tools, but I 
have not seen an analysis of the procedure and why it fails.
(But I might have missed it in the long thread.)

So I dare to ask the question again: What is wrong on

1)   working on trunk, the bleeding edge

2)   branching out for release when the trunk is
      release-stable
2.1) feature freeze and stabilizing, merging relevant
      parts to trunk

3)   releasing from release candidate branch, i.e. tagging the branch
3.1) bugfixing on branch, merging to trunk, tagging the branch

Is it this procedure that is broken, or is it the tools that are 
insufficient to support this procedure?

In this scenario there is also always a release-ready branch insofar as 
a branch, once released still is release-ready (e.g. for fixing).

And there is nothing that can potentially destabilize a branch that has 
already been forked out. There is also no requirement that a release 
branch ever dies. Bug fixes still can go there after it has been tagged.

I also see nothing wrong with multiple release candidate branches at the 
same time. A release branch simply is another name for a certain set of 
features that are covered.

No resources to test everything?
Only a reported failure indicates something being wrong, that needs to 
be fixed. So I think it only fair to ask the reporter to help with 
testing by providing access to her environment and spend the necessary 
processor cycles to fix the problem. (Of course we would need the tools 
that would allow us this kind of on demand remote testing.)
(This kind of support is also where developers could earn money if they 
like.)

A potential user just browses through the testing pages and selects the 
most up to date release that covers the required features. (With the 
option for bug-fixing if something does not work for his environment.)

Of course in this scenario the release manager would have less work to 
do :-D . Just watching out when a agreed feature set is in the trunk, 
and branch when there. (Of course developers always try to hold trunk
as stable as possible ;-) )

Another potential benefit of this model is that developers already are 
used to it.

So my bottom point is to generalize the current model to what I have 
said above and concentrate to get better tools that support this.

AFAIK this is also the model other big monolithic projects are using.
Departing from it would require modularization of the boost library, 
which at the current state does not look like an easy task to me.
A small example:
I was trying to single out the asio lib, and discovered that it had 
quite some implicit (undocumented) dependencies on other 
header-only/prebuilt libs. Only when I tried to use auto_link on an msvc 
platform with BOOST_LIB_DIAGNOSTIC turned on I eventually figured out 
that I also had to provide boost_system boost_date_time and boost_regex 
to the linker while compiling with gcc. So the recipe I once heard on 
this list: just take the relevant files and copy to your directory if 
you don't need all of boost, is hoping at best.

Roland aka speedsnail