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.
> 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
* Avoiding completely silent breakage
* Using a deprecation period to give users notice that a breaking
change is coming
* Documenting a transition procedure
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk