Re: [boost] Breaking existing libraries

Subject: Re: [boost] Breaking existing libraries
From: Robert Jones (robertgbjones_at_[hidden])
Date: 2008-11-21 03:54:38

On Fri, Nov 21, 2008 at 8:26 AM, Markus Werle
<numerical.simulation_at_[hidden]>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.