From: Gubenko, Boris (boris.gubenko_at_[hidden])
Date: 2008-08-18 11:07:47
I think release-specific "hot fixes" could be useful. Perhaps, only changes preserving binary compatibility should qualify as hot fixes for a release. Also, I think only changes that are part of trunk code and, as such, are tested by the Boost regression testing should be allowed as hot fixes.
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Beman Dawes
> Sent: Monday, August 18, 2008 10:32 AM
> To: Boost Developers Mailing List
> Subject: [boost] Should we provide hot fixes?
> 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?
> Hot fixes might work something like this. (I'll use an embarrassing
> Boost.Filesystem mistake I made as an example.)
> * Individual developers will decide on a case-by-case basis
> if they want
> to provide a hot fix for a given bug.
> * There would be a prominent link on the web site to a "Hot
> Fixes" page
> in the trac.
> * That "Hot Fixes" page would have a section for each release.
> * Under release 1.36.0, there would be a changeset number, a
> of the problem, and a directory-location:
> 48192 Restore deprecated basic_directory_entry names
> inadvertently removed. (boost/filesystem)
> * The changeset number would link to
> * The "Hot Fixes" page would include instructions on how to apply a
> changeset. The instructions are the same for all operating systems:
> -- Click on "Download in other formats: Unified Diff".
> -- From the command prompt,
> cd directory-location
> patch <download-location/changeset_r48192.diff
> * The "Hot Fixes" page would include instructions on how to install
> "patch" for popular operating systems, and give an example of
> actual usage.
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk