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