Re: [boost] What Should we do About Boost.Test?

Subject: Re: [boost] What Should we do About Boost.Test?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-18 20:44:44

Le 19/09/12 01:35, Robert Ramey a écrit :
> Mathias Gaunard wrote:
>> Isn't Boost.Test's only problem the fact that other Boost libraries
>> are tested against the trunk rather than the release version?
>>
>> Isn't that something the modularized Boost is supposed to fix?
> There's no need to wait for "modularized Boost" to start doing this.
> This could be done now with relatively modest (though of course
> tricky) adjustments in the test script.
>
>
Hi Robert,

IIUC, your strategy to tests has some advantages, but it has some 
liabilities also:

* every developer should use the same strategy,
* the trunk will surely be broken as no one is testing with the trunk of 
the others libraries,
* it delays the day conflicts are evident to the day the developer 
merges to release, as no one has tested with the new changes.

I think the authors of the Boost libraries should try to avoid the 
introduction of breaking changes. Breaking changes should be manage 
using versions and deprecated periods.
If this were the case, new features could be added in trunk without any 
problem, and the authors could have enough time to move to the new 
breaking ones.
Even when we will have a modularized Boost, we should manage with 
breaking changes in the same way (versions and deprecated periods).

Of course we are all subject to making some errors, but at least we 
should have in mind the consequence of unexpected breaking changes.

Best,
Vicente