Subject: Re: [boost] Breaking existing libraries
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2008-11-21 12:06:29
> 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)
>> 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
>> *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
>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
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
compiler testing will show up this bug.
As a potential middle-road (and given the size of boost now), one
way forward would be to break up boost into a "stable" and "new"
Our developers frequently want to use some new library from boost.
since boost is always rolled out as a big package, this is not possible
as I've mentioned before, doing an entire re-release of all internal
built on new boost is non-trivial, along with the fear that some major
(such as boost::function) was been broken.
However, if there was a "stable" boost platform to which we could add
without worrying about breakage/incompatibility, we would be far more
to bring in new libs. In return, boost would get additional testers,
mention that I think some of the preconceptions about instability would
alleviated. Furthermore, it may become unnecessary to have frequent
releases, as people could just get "stable" and then a "latest tested"
of the libraries they need or of the "new" branch.
It would be necessary to decide what "new" and "stable" means; I'm sure
core could be decided fairly easily (and the fringes will be argued
Then what is needed is a policy on how a component becomes "stable" as
to "new" (e.g. 1/2 years in production). All changes to "stable" have
through a review and cannot be brought in a single release - they must
deprecated and a migration path provided.
I'm not saying this is easy. Just a few thoughts I'm having.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk