From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-07-15 18:50:04
On Tue, Jul 15, 2008 at 4:13 PM, Robert Ramey <ramey_at_[hidden]> wrote:
> My proposal would:
> a) save a lot of wasted time looking for problems which in fact
> are side effects of some un-anounced breaking changes.
> b) make better use of boost test resources by running tests
> in a controlled manner rather than testing on a moving platform.
> c) Improve boost by discouraging breaking changes.
> d) Improve boost by usually having ready the "next release"
> thereby short circuiting calls for "point releases, etc"
Quoting your proposal:
---- "Proposal:All tests for a particular library should be run against the latest or next release." "Proposal:Libraries which have been tested against the latest or next release are merged into the release one at time and tests are run on the "next release". Failures here indicate interface breaking changes which would either be rolled back or addressed in each dependent library." ---- Let's consider the serialization library. If I understand your proposal correctly, it would be tested against the last and the next Boost release, but not in the trunk jungle. The aim of this testing is to prove that, if the test with the previous Boost release succeeds but the test with the next Boost release fails, a library that the serialization library depends on has introduced a breaking change which has to be fixed. However, the quoted proposal does not at all discourage breaking changes; it only detects them (and in fact it postpones the detection.) My suggestion was to formally flag certain libraries as frozen. The exact semantics of the "frozen" flag could be that any breaking change is a bug. This does discourage breaking changes (in those libs), and as far as I can tell achieves your goals, except that: A) breaking changes are detected as soon as they occur, and B) it allows for breaking changes in non-frozen libs to be treated as features and not bugs. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk