Re: [boost] Breaking existing libraries

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
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.  In return, boost would get additional testers,
not to
mention that I think some of the preconceptions about instability would
be
alleviated.  Furthermore, it may become unnecessary to have frequent
point 
releases, as people could just get "stable" and then a "latest tested"
snapshot
of the libraries they need or of the "new" branch.

It would be necessary to decide what "new" and "stable" means; I'm sure
the
core could be decided fairly easily (and the fringes will be argued
forever).  
Then what is needed is a policy on how a component becomes "stable" as
opposed 
to "new" (e.g. 1/2 years in production).  All changes to "stable" have
to go 
through a review and cannot be brought in a single release - they must
be 
deprecated and a migration path provided.

I'm not saying this is easy.  Just a few thoughts I'm having.

Tom