Re: [boost] [1.36.0] Libraries with unmerged changes?

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