Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2008-11-24 02:58:50

vicente.botet wrote:
> ----- Original Message -----
> From: "Johan Nilsson" <r.johan.nilsson_at_[hidden]>
>> "vicente.botet" <vicente.botet_at_[hidden]> skrev i meddelandet
>> news:3E6A91215D384FF9AD7BFB070DDD16F7_at_viboes1...
>>> ----- Original Message -----
>>> From: "Johan Nilsson" <r.johan.nilsson_at_[hidden]>
>>> To: <boost_at_[hidden]>
>>> Sent: Friday, November 21, 2008 1:02 PM
>>> Subject: Re: [boost] Breaking existing libraries
>>>
>>>
>>>> Just an idea that popped out of my head - what about running (or
>>>> at least compiling) the unit/regression tests from the _previous_
>>>> major release against the current release as a way to
>>>> automatically detect and flag interface/behavioral changes?
>>>>
>>>> Sure, there are many potential problems with such an approach:
>>>>
>>>> - Some library tests are likely to also excercise code at the
>>>> implementation/detail level.
>>>> - Already limited testing resources (on the other hand, interface
>>>> changes are likely to be detected by running such tests for a
>>>> single, reasonably compliant, compiler).
>>>> - ...
>>>
>>> In order to have the better the author can preserve the test of the
>>> older releases and run them on the current release.
>>
>> Sorry, I don't follow you.
>
> Daniel Walker has expresed this better
> "Once accepted, the tests
> should be a verification that the library does what the community
> voted on. The tests are a verification of quality. At that point, I
> think it might be a good idea to quarantine the tests, take them out
> of the authors hands, and put them under the stewardship of a
> benevolent dictator of boost as a whole so that they can be used to
> assure that the library does what the community voted on.
> "

Sounds like a good idea in general. Reference, please.

> If we need to change while we make evolulion on a library this is a
> symptom the interface has changed and the same way the test is
> broken, the user code canbe broken. If we forbid this test changes,
> we are able to identify breaking changes.

In order to truly make such a thing work, I think it would be neccessary to
separate interface and implementation tests.

There is almost always a need for testing implementation details,
which should be free for the author to change (and improve upon).

How do you think extensions to the interface should be handled?

/ Johan