on Fri Nov 21 2008, Markus Werle <numerical.simulation-AT-web.de> wrote:
Tomas Puverle <Tomas.Puverle <at> morganstanley.com> writes:
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: [...] Apart from the fact that this change breaks a lot of our code and obsoletes several useful (necessary?) idioms, the manner in which it happened is far below the standards that one has come to expect from boost. [...]
In advance: I suffer from breaking changes in boost all the time and bite the table plate quite often. Indeed we have a problem here. The changes in e.g. spirit are a drama and I fear the day I have to check all of my (absolute stable) parser code, just in order to get things up-to-date, introducing a plethora of new bugs in code I did not want to touch again. [Sidenote: I'd prefer boost::spirit to stay as it is and spirit2c be renamed to boost::ultimate_parser, since it is a *completely* *different* library.] The boost community has not found the perfect way to deal with breaking changes yet, since this is an issue that cannot be easily solved.
It's something that we could easily do better.
OTOH:
There is a tradeoff between quality of implementation and innovation that we all have to live with. Boost is a project traded by volunteers with an aim towards bleeding edge technology, not always waiting for customers to nod. Boost developers sometimes move faster than lightning (try to follow the code changes made by Eric Niebler for 2 weeks just to get an impression) and if you compare the collateral damages of this to the benefits I would still give the boost community a higher credit than Microsoft (they break everything every 3 years and no one even tries to complain).
The key issue is: You did not pay for what you use.
I'm sorry to contradict, but I don't think that's the key issue. IMO, the key issue is giving care to disoverability and the ability to make a transition: * Avoiding completely silent breakage * Using a deprecation period to give users notice that a breaking change is coming * Documenting a transition procedure * ....etc.
The Good News (TM) is that you can pay for it now: People at boost-consulting can help you with your problem within a week or so (middleman fees to me, please ;-)).
I'll see if there's something we can do ;-)
But let us go back on the we-do-not-pay-for-it path: IMHO it is a severe error of your development process that you do not check your code with new versions of all compilers and all libraries on a *regular* basis.
I agree that testing needs to be made more regular and thorough. However, IMO the universe of compilers and libraries is much too large --- and in some cases, the software is too expensive --- for us to check code with new versions of *all* compilers and *all* libraries. We need to select a subset against which we'll test. -- Dave Abrahams BoostPro Computing http://www.boostpro.com