Vladimir Prus wrote:
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?
I think this is something the the Release Manager and only the Release Manager should do. Although the most convenient way to do this is still the subject of experimentation I would envision the following: a) A library author presents argument/evidence that his changes in the trunk or in a private branch will not break anything in the next release. b) The release manager evaluates the request and either accepts it or rejects it with an explanation or counter request for more testing or whatever. c) If its accepted, the release manager merges the authors changes from whereever they have been checked in, maybe runs some library specific test on his own. d) The release manager then generates the tarball and uploads it the designated area and request full testing on it. e) If the testing results show an improvement over the current version, anouncement is made and the latest tarball is designated the most recent official release. f) The release manager has the descretion to bundle more than one set of changes in a release. He might want to do this to save time if the changes are ready at the same time and he sees them as unlikely to conflict. I order to accomplish a) above with the current tool setup, The following kind of process is envisioned. i) The developer keeps a copy of the next release on his machine. ii) He switches the directories corresponding to his library over to the place where he has checked in his changes. This might be the trunk or a private release branch. iii) He runs local tests. I've created library_status with this purpose in mind. iv) If he's satisfied and want's help testing on other platforms. He finds a willing collaborator to do the test same test on HIS platform. Note that this testing is quite fast as its only one library. Personally I would recommend that this testing be for all likely build variations <variant>build/release, <link>static,shared, <threading>multi,single The tester can report the results back to the author. Currently there is no documented way to do this conveniently. But I feel this could be done with little effort. Again I created library_status to permit browsing of the accumulated results in a convenient manner.
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree.
At the option of the release manager, the changes are rolled back or the bug is fixed in the release-ready tree.
Week later, a serious bug is found in another library. Is there a place where that bug can be fixed?
If the bug is found in the release ready tree, the release manager has the same two alternatives described about. Ask for fix or roll back. It's up to him
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?
Release 1.35.1 is released when the released manager feels that its a significant improvement over the previous release. He has the authority to merge in changes and rollback.
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?
Similar to the testing which has been done on the release candidate in the past. The difference is that it would only need be done when requested by the release manager after he has merged something in.
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.
I would not expect the release manager to approve this and merge in such changes unless they are of a very small and/or trivial nature. He will have to weigh the risk as he's stuck with the consequences. (1) requires on-demand testing of branches. Is (2) the way to go? Yes it is. For now we can just do it in the informal/ad-hoc way described above. Assuming it works out, this process can be made more automated.
Concerning (1), your definition of release ready will prevent merge if there even a single regression.
Generally this is true. The release manager would have the option of making a change in the release-ready branch. The occurence of this situation signals a like interface-breaking change so rolling back might seem drastic, but its likely that the change has larger implications that one test failure shows. So if I were release manager, I would be predisposed to just punting back to the library author(s) to address. *** As a "test" of this new procedure, I think we should try it with 1.34.2. This would be targeted for 15 October 2007 This could/include a) Joaquins Multi-index which he claims to have tested against 1.34.1 b) build system corrections/improvements c) Any other libraries whose authors want to submit evidence that their recent changes haven't broken anything. The only question would be the recruitment of the release manager - LOL Robert Ramey