Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-11-21 03:26:20

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).

regards,

Markus