David Abrahams wrote:
on Thu Nov 20 2008, Tomas Puverle <Tomas.Puverle-AT-morganstanley.com> wrote:
You may or may not have noticed a thread I started on boost.users about the breaking changes to Boost.Range. Here’s a short summary: We are currently (firmwide) using boost 1.33.1. I am in the process of trying to migrate and test some of our apps with boost 1.37. In 1.35 there was a breaking change to Boost.Range with respect to how singular ranges behave. This brings up several issues:
[snip]
At the moment, I have to say I don’t have a good answer to how to fix our code. However, I would at least like to try to make sure this kind of silent breakage doesn’t happen again.
Hi Tom,
Yes, this is an unfortunate situation. If you indeed want to try to make sure this kind of silent breakage doesn’t happen again, there's something you can do about it: write a page of library maintenance guidelines on the wiki at http://svn.boost.org. We are sorely missing a policy on this, and when less-experienced library authors come along, they often don't hew to the same standards that many of us take for granted. If you don't have write permission for the wiki, please let us know and we'll send you an invitation.
Just an idea that popped out of my head - what about running (or at least compiling) the unit/regression tests from the _previous_ major release against the current release as a way to automatically detect and flag interface/behavioral changes? Sure, there are many potential problems with such an approach: - Some library tests are likely to also excercise code at the implementation/detail level. - Already limited testing resources (on the other hand, interface changes are likely to be detected by running such tests for a single, reasonably compliant, compiler). - ... Anyway, this is mostly me thinking out loud; perhaps someone smarter than me could expand on the feasibility of such an idea. / Johan