2008/5/23 Peter Dimov <pdimov@pdimov.com>:
Well the testing of "branches/release" has never stopped.
It doesn't matter, because the current state of branches/release is largely irrelevant (except if released as 1.35.1).
I don't think it should be a question of if released as 1.35.1, but I think it should be a given that if bugs are present in a particular release, that can be fixed, keeping as much of the ABI/API the same then these bugs should be fixed. Since large changes are allowed in modules between point releases then it is useful to have bug fix releases that fix issues with the release since upgrading may not be an option, due to time constraints or project budgets, if there has been a API change, so its useful to have working versions of a release.
What is relevant for 1.36 is the state of branches/release after the merges from trunk are done, and this isn't being tested, because it doesn't exist yet.
As to branch management I think that the best method for boost will be to name the branches after the major release number i.e. so the next release development will be occuring on branches/release1_36 and not just branches/release. This makes repository management a lot easier in the long term too (should boost move to a distributed version control system this branching convention will be a lot easier to import). So what I would propose is this: branches/release gets moved to branches/release1_35 and a 1.35.1 release be made from fixes on this - not a huge amount of work since essentially just patching up from trac bug reports, ensuring changes are also merge on trunk and release1_36 (where applicable). branches/release1_36 gets made from trunk asap Then development for 1.36 happens alongside 1.35.1. Ideally the branch for 1.36 would have been made after feature freeze for 1.35 occurred. The reason for this is that it enables trunk to become a stabilising area for features for the next release i.e. it implicitly becomes release1_n+1(any features not ready for integration should be developed on a feature branch branched from trunk to be later merged back to trunk). Before 1.35 was released I did try to start discussion that 1.36 should be branched before the actual release (i.e. when a feature freeze began) and that the release team for 1.35 should then continue to manage the branch for bug fixes and that a second release team should begun integration for 1.36. I think a good model for boost's release procedure would be one similar to that of the linux kernel. Having a merge window for a particular release for new features, then a stabilization period before releasing could suit boost well due to the nature of the project. James