Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at