Boris Schaeling wrote:
On Sun, 21 Mar 2010 05:55:14 +0100, Artyom <artyomtnk@yahoo.com> wrote:
The point where that breaks down is where one library
is found to have a fatal flaw shortly after a release, you wait 6 months (or whatever) for another version of boost which fixes the bug, but also breaks the API on a half-dozen other libraries you use.
This is then really a problem with testing if such a disastrous bug slips through?
I think that it is terribly wrong assume that Boost can release any kind of bug-free library even free from terrible, critical bugs that make the library useless. It is programming world. There is no such thing like bug free software. See UUID example...
I would propose then to add a patch system to bjam? If bjam supported patches (in order not to depend on various tools on different operating systems) those who urgently need a fix wouldn't need to wait for the next official release?
Why would Boost.Build support patches? The procedure for making maintenance release is pretty straigh-forward: 1. "svn merge -c" the fix to maintenance branch. 2. create a tarball/zip from the maintenance branch If there's interest, I can actually do it. [There's the problem that SF file release system is a bit convoluted and not-scriptable, but we can bypass it completely, just like it's done for Boost.Build nightly builds] - Volodya