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