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" <Tomas.Puverle-AT-morganstanley.com> 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 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