Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-11-23 13:51:06

----- Original Message ----- 
From: "Johan Nilsson" <r.johan.nilsson_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, November 23, 2008 7:27 PM
Subject: Re: [boost] Breaking existing libraries

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

Vicenet