From: David Abrahams (dave_at_[hidden])
Date: 2008-07-16 10:06:44
on Wed Jul 16 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:
> On Tue, Jul 15, 2008 at 10:29 PM, David Abrahams <dave_at_[hidden]> wrote:
>> I was talking about relying on dependent libraries catching bugs in a
>> dependency (e.g. serialization's tests uncovering breakage in type
>> traits). Sounds like you're talking about the other direction, sort of.
> I agree that we don't want to rely on dependent libs to catch bugs in
> a dependency, but sometimes this does happen.
> When a serialization
> library test fails, we can't without further investigation assume that
> some other library is to blame, even if the serialization library
> tests pass with the last and the next release of Boost.
Now you seem to be making the opposite point; that it might be a
>>> For example, you might depend on an implementation detail of another
>>> library without knowing it (note that "not knowing it" isn't always a
>>> matter of being careless.)
>> It isn't?
> Not always. For example, the dependency may be indirect, through
> another library. Or, it might be due to buggy or incomplete
Somebody was careless in that case.
>>> This might become source of regressions, which are typically
>>> undetected until the implementation of the dependent library changes.
>> Sure. What's your point?
> That it is a bad idea to avoid testing an (even stable) library
> against the (unstable) trunk just because this may produce bogus
OK, I guess
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk