Beman Dawes wrote:
Although it does look like we will be able to hold to a quarterly release schedule, it is really doubtful we have enough resources to issue point releases.
To get bug fixes into user's hands more quickly, should we provide hot fixes when appropriate?
NOOOOOOOOOOOOOOOO!!!! <deleted proposed procedure below> This create a whole new procedure. I think taking the current one to its logical conclusion will get you want you want with much less effort. Here is what I suggest. a) You make the fixes you want on your own machine, branch or whatever. b) Test them against the "current release ready" version. Right now that is the release branch which is currently at 1.36. This branch should be tagged via SVN to be named "1.36". c) Merge them into the trunk. d) Request permision from the release manager to merge them into the "current release ready", I this case I would expect that such permision would be granted without problem. e) Merge changes into the "current release ready". f) Wait for testing on "current release ready" branch to complete. At this point there are a couple of options a) Just inform users that the "hot fix" is in the "current release ready" branch an that he can either sync with this release with SVN or just patch his own system. b) Tag the "current release ready" branch as "1.36.1" c) Optionally create a new tarball and upload etc. Note that this last item presumes the release procedure is implemented as some sort of command like "BuildReleasePackage" <SVN tag> and that the release procedure is fully automated. Which in turn presumes that it is tested whenever something it depends upon changes. So the procedure should be part of boost/tools/with its own small test suite. Thus it could be tested and debugged on a small / simple dummy release with "BuildReleasePackage" dummy Robert Ramey