On Tue, Jul 15, 2008 at 5:52 PM, Robert Ramey <ramey@rrsd.com> wrote:
Here is where we differ. Now when someone checks in a breaking change. errors pop up all over the place in test results that the author who caused the problem doesn't have any reason to check. He who has had his library broken has to investigate the cause of the sudden breakage and trace down to its source and then complain. This is a huge pain in the neck and costs a lot of time and frustration.
You're making a big assumption here, which is that the breaking change is a bug. Here is an example: adding the Exception library "broke" several other libraries that were throwing ints or enums through boost::throw_exception. The fact is that boost::throw_exception has always required that its argument is of type that derives from std::exception, but it did nothing to enforce this requirement. Now it does enforce it which exposed the bugs in the other libraries. This is a good thing. In your mind, shouldn't the maintainer of each Boost library be responsible for investigating errors in their own tests, even though it is pain in the neck and costs a lot of time and frustration?
I would ask that library authors that cannot make a similar pledge include a disclaimer in thier documentation and header files something on the order of: ... You can ask anything you want and you can assume anything you want about Boost libraries, but the fact is that they do change and occasionally breaking changes are introduced, which may or may not be regressions.
Shouldn't we have release procedures that address this _fact_? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode