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

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-07-15 20:52:52

Emil Dotchevski wrote:
> "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.

Currently I run the serialization tests against the latest boost
releases.  I do this on my own machine.  Any failures must then
be due to recent changes, added features, etc.  I do this
even before checking in.

> The aim of this testing is to prove that, if the test with the
> previous Boost release succeeds

Then I haven't broken my library.

> 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.

Correct.

> However, the quoted proposal does not at all discourage breaking
> changes;
> it only detects them

OK I would hope that this would discourage breaking changes.

(and in fact it postpones the detection.)

Here is where we differ.  Now when someone checks in a breaking
change.  errors pop up all over the place in test results that the
author who caused the problem doesn't have any reason to check.
He who has had his library broken has to investigate the cause
of the sudden breakage and trace down to its source and then
complain.  This is a huge pain in the neck and costs a lot of
time and frustration.

> 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.

LOL - that's my view exactly. The only difference is that I think
all libraries should be considerd "frozen".

SO:

I, Robert Ramey, hereby declare:

a) the serialization library to be "frozen".
b) the documented interface and symantics will only be extended - not 
changed
without notice.
c) should any program which depends upon the published interface and 
semantics
fail to work or stop working - I will acknowledge that this is a BUG
and endeavor to fix it.
d) Going further (specific to the serialization library) - the intent of the 
serialization library
 is that newer version be able to load files saved by all previous versions.
Any case where this fails will be acknowledged as a BUG.

I would ask that library authors that cannot make a similar pledge include
a disclaimer in thier documentation and header files something on the order
of:

"I (the author) expect to make future changes in this library.
These changes may have the effect that in the future you're program
will fail to compile, link, and/or execute as expected.  Since I don't
know who might use this library, it is impractical for me to
notify you - Sorry about that - Good Luck."

That would permit me as a user to take appropriate precautions.

> 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

I disagree here - see above.

> B) it allows for breaking changes in non-frozen libs to be treated as
> features and not bugs.

LOL - this view point is shared by many, perhaps the majority, of
people in the software development community.  It is the bane
of modern software, leading to composition of components that
together produce, quirky applications that can be made work
only with a disproportional amount off effort and frustration.

Robert Ramey