Peter Dimov wrote:
Robert Ramey:
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.
What's the alternative? In Boost release 1.36, libfoo 1.36 has to work against Boost 1.36, not Boost 1.35.
In my view it should work against both. If not there's a bug.
Testing it only against Boost 1.35 allows one to be smug and claim that any failures aren't one's fault,
LOL - well there is that. But note that I'm not suggesting that this be the only testing done.
but doesn't help the release process.
Trunk does, by testing tentative libfoo 1.36 against tentative Boost 1.36.
Sort of.
Exactly. That's my complaint about it. One reason my proposal isn't as clear as it should be is that the current concempt of 1.35, 1.36 would be a little blurred. Given a "release ready version" which is used for testing and ready for release when the quarter comes aroud effectively means that there is a release 1.35.1, 135.2, 135.3 .... each time a tested library is merged in. The only thing special about the 1.36 release is that it would be packaged in a more complete form , tarball, etc. Robert Ramey