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