From: Robert Ramey (ramey_at_[hidden])
Date: 2008-08-18 16:11:14
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?
<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
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk