On Fri, Nov 21, 2008 at 8:26 AM, Markus Werle <numerical.simulation@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.
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. 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 ;-)).
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. In management parlance: your risk management is defective. It always is a good idea to use the svn repo of boost and the beta version of the next compiler just to see the breaking changes early enough, which gives everyone plenty of time to react.
Version 1.33.1 is from the stone age (remember boost is moving faster than light[ning]) and I always expect things to be broken the next time (which is not nice, but compared to the problems solved by boost this still can be neglected).
This is a very useful post, and makes some excellent points. In particular this cuts to the very core of what Boost is. There are, I'm sure, various statements throughout the site concerned with the 'Boost Mission', but in reality it it is very much a moving target and constantly evolving. However, as a group we do tend to be a bit schizophrenic about this, and about balancing the 'technical showcase' aspects with the 'reliable product' aspects. We do, in my opinion, encourage the use of the libraries in commercial products, and as such it seems to me that we have a duty to be mindful of that in our practices and policies. Failure to do that will result in the Boost project becoming marginalised as just a bunch of (very highly skilled!) hackers, which would be a shame. Alarmingly I already see that happening in some companies I've worked in, in which less progressive elements exploit exactly these kind of perceived weaknesses to spread Fear, Uncertainty and Doubt. As with everything it is ultimately about balance, and my feeling is that these changes to the Boost.Range library do not balance these considerations well. - Rob.