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 turnaround.
-- 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 servers. 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 wget boost.org/1.36/hotfixes for fix in hotfixes do # only apply new fixes if test ! -f applied/$fix then wget $fix || exit 1 patch -p0 < $fix || exit 1 touch applied/$fix fi done - Daniel