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

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-16 02:09:14

Emil Dotchevski wrote:
> 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.

LOL - I call it a bug - you can call it a feature.  Regardless,  it is an 
(unannounced)
interface change.

> 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.

This isn't the case being discussed here.  Of course a developer can't
be responsible for usage of the library which is not in accordance
with it's interface and semantics.

> 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?

Of course he's responsable.  But the job is bad enough without
random hand grenades being tossed into the mix.

>> 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,

I'll consider that a disclaimer.

I don't think you can speak for other library authors on this point.  I
know you can't speak for me here.  I'll say it again: If anyone discovers
an iterface/semantic change in the serialization library - it will be
considered a bug.  And I won't unleash changes in interface/semantics
except under the most extraordinary circumstances.  So far
this has never occured.

> which may or may not be regressions.
>
> Shouldn't we have release procedures that address this _fact_?

And that's the problem with the current proceedures.  Changes
in one library break other libraries and there is no obvious
method of knowing the cause of the problem.  My proposal
DOES address this when interface breaking library is rolled
in to the release.  At this point all new test failures must be
due to such an interface change.  They can then be addressed
one way or the other without every library author having to
rediscover the cause of the problem.

I don't think the issues you've raised argue against the
utiltiy of my proposals.  Rather the contrary.  We'll have
to agree to disagree.

Robert Ramey