Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted: 1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything. Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still? 2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released? 3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree? Trunk might be in the middle on the next big change, so a fix can either (1) be made on brunch and then merged, or (2) be made on release-ready tree directly. (1) requires on-demand testing of branches. Is (2) the way to go? Concerning (1), your definition of release ready will prevent merge if there even a single regression. And (2)-(3) are not addressed at all, as far as I see. - Volodya