Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-21 06:47:19

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