Date: 2008-08-18 18:31:51
On Mon, 18 Aug 2008, 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?
Yes and no. Yes -- trivial bloopers shouldn't require a 3-month
> -- Click on "Download in other formats: Unified Diff".
> -- From the command prompt,
> cd directory-location
> patch <download-location/changeset_r48192.diff
No -- this is too complex. For any reasonably large project, instructions
beyond "install version 1.36" are generally ignored. I've already had the
fun of helping distribute in-house tarballs for boost, setting up my own
tests, server, etc. so people wouldn't have to slurp 1.35+ from SVN.
Much better would be if these "hotfixes" could be applied to the release
(and trunk) branches, tested against the usual mechanisms, and released as
a micro version number. Then everyone gets the update from the main boost
Of course this puts more work on the release manager's shoulders, so your
opinion may differ. But these hotfixes should truly be trivial; thus
testing should be easy, and it gives you more opportunities to test the
release system. :) For anything nontrivial, I'd point people to the
appropriate SVN branch. And nontrivial things generally motivate
end-users to jump greater hurdles or just wait a few months.
Another possibility would be to distribute a boost-hotfix.sh script along
with boost releases. If it contained a hard-coded path to boost.org, then
users could run boost-hotfix which would automatically download and apply
any patches which had been uploaded properly.
This script would look something like
for fix in hotfixes
# only apply new fixes
if test ! -f applied/$fix
wget $fix || exit 1
patch -p0 < $fix || exit 1
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk