I understand that as boost gets bigger it gets harder to make new releases. There is more to do, more to keep in sync, and more ripple effect in changes. I see this more structured and formal release procedure as an attempt to deal with this. It seems to aim for a closer coordination of developement and release efforts to avoid difficulties associated with development of software libraries which have varying degrees of coupling. I sympathize with with the effort. I would summarize the general idea as getting developers more "in sync" through different stages of development and release. I see this as getting more difficult as boost gets bigger and more diverse. The development of different libraries can't really be "scheduled". So I think this is the wrong approach and I think it will make things harder rather than easier. I would propose a different way of going about this. Here it is. For the moment, exclude those packages related to building and testing from consideration - I'll address those at the end. a) developers build and test their libraries on their local machine against the latest release. b) when they think they are ready, they open a branch on the main trunk and check in their "next release". So the cvs system will have a branch for every developers "next release" c) when checked in - the developer will queue up a test request on the new branch. d) when the the test results show that the "next library release" is "ready", the branch is merged with the main trunk. The complete regression test is then run. There "should" be no new errors but there might be cases where the library developer has inadvertently changed some undocumented behavior which might show us as some error. Also there might be cases where the other parts of boost detect an error which has not been detected in the library test suite. These should be only a few cases. e) Once tests a d) above pass, the boost library version is incremented and a new release is emitted. f) At this point, working developers would update their local development copies of the CVS tree. In this system: a) Each library could be developed at its own pace an schedule. There would be not rush to "make the next release" with all the problems that that causes. b) The latest release of Boost would more up to date. That is, one wouldn't be in the situation of needing the next ehancemet, knowing its already in there but not being able to use it because the next release isn't ready yet. c) Testing resources would be used much more efficiently. Basically more testing would be focused on areas that are likely to have problems and less testing is focused on things that "almost for sure" should pass. Testing would be done only where and when changes have been made. Code for building and test are special cases and would have to be considered individually. Certainly Jamfile/toolset updates could be work with the above system. Movement to V2 wouldn't fit here and would have to be considered how to do this. Boost.Test enhancement would require some consideration as well. In general - code breaking changes would have to be considered specially. Basically, I don't believe the current Boost developement model is scalable and I think the procedure has to change to recognise this. So in my view the current proposal goes in exactly the wrong direction. Note that this is starting to occur by necesity. Multi-index has a "beta" version compatible with 1.33 that one can download. I've been testing changes to serialization on my machine against 1.33. I haven't checked them into the HEAD. So now I know what problems are mine and what problems are associated with changes in compiler versions, stlport versions etc. My next step is to make a few more changes, run some more tests locally (basically later version of stlport) and upload a package similar to Joaquin's. This would make the changes (mostly bug fixes and documentation upates) available to those who need them now and also give those who want to help me out a way to test my changes without waiting for the next release when it will be too late to fix anything. Robert Ramey