Re: [boost] [1.36.0] Libraries with unmerged changes?

From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-07-15 20:15:33

On Tue, Jul 15, 2008 at 5:52 PM, Robert Ramey <ramey_at_[hidden]> 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