I should say I think this is really great. This give users the option to upgrade to a tested package without having to wait for 1.37. I do have one suggestion. I have a release tree on my machine. I'm concerned that I accidently check in a change into the Release tree when I mean to check in to the trunk. I would not want to be responsable for creating any more havoc than necessary. To this end, I wonder if wouldn't be a good idea for the release manager to lock the release branch. This is easily done with SVN. He could then unlock it for specific merges or do the merge himself - which ever he prefers. I don't think it would be a huge burden as I see these kinds of check-ins occuring a few times/month and the amount of effort to lock/unlock the branch is very small. It would also prevent the possibilty of the release manager getting caught with his pants down by some accidental or untested change he wasn't aware of. and another suggestion. I keep a release branch on my machine. The serialization library directories have been switched to the trunk. So I can test against the latest release ready version of boost. This gives me a lot of confidence that when I merge my changes into the release branch (subject to release manager approval of course), that I won't have any surprise breakages. Robert Ramey Eric Niebler wrote:
I'd like to merge Proto from trunk to release. The API is stable, the tests are now passing on most toolsets (though it's hard to see from the test results at the moment because of a Boost.Test bug), and much of the review feedback about the docs has been accommodated. I still plan to make doc improvements before 1.37, but I don't think that should hold up the show.
OK to proceed?