Le 19/09/12 01:35, Robert Ramey a écrit :
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
Mathias Gaunard wrote: 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