Boost logo

Boost :

Subject: Re: [boost] Breaking existing libraries
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-21 13:07:26

on Fri Nov 21 2008, "Tomas Puverle" <> wrote:

>> The key issue is: You did not pay for what you use.
> I am sorry to disagree but this will not solve anything. The fact is
> that we use other open source projects where we pay for support and
> the supporting organization still doesn't guarantee that nothing will
> break. The moment they tried, the other people would branch off the
> code. There has to be an agreement among the developers themselves
> and commitment to quality of implementation.
>>> 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 ;-)
> So can we pay you to roll back Boost.Range? ;) (This doesn't
> constitute an offer to buy or sell or do anything)

In a manner of speaking, yes. However, I want to be careful not to
abuse this forum for commercial purposes, so if you want to discuss it
further, please contact me off-list.

>>> 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.
> Agreed. I think in general boost is very good at this and I feel
> developers are fairly happy to contribute back any changes to make
> boost work on a particular compiler. This issue is not about my code
> not compiling - my code compiles, it just does something completely
> different. No amount of compiler testing will show up this bug.
> As a potential middle-road (and given the size of boost now), one
> possible way forward would be to break up boost into a "stable" and
> "new" branches. Our developers frequently want to use some new
> library from boost. Unfortunately, since boost is always rolled out
> as a big package, this is not possible because as I've mentioned
> before, doing an entire re-release of all internal libraries built on
> new boost is non-trivial, along with the fear that some major
> component (such as boost::function) was been broken.
> However, if there was a "stable" boost platform to which we could add
> new libraries without worrying about breakage/incompatibility, we
> would be far more likely to bring in new libs.

Which versions of the "stable" library would the "new" libraries be
required to work with?

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at