Subject: Re: [boost] Stability: More on 3 level Boost libraries
From: Rene Eng (gemini67_at_[hidden])
Date: 2010-03-26 03:37:15
2010/3/26 Gennadiy Rozental <rogeeff_at_[hidden]>
> Rene Eng <gemini67 <at> gmail.com> writes:
> > - You have to maintain 3 sets of the Boost library that are in itself
> > compatible.
> I might have missed it, bu t I thought this discussion was not about 3
> of the library. This is definitely, not something I'd support.
We are talking about three levels of library quality.
As an end user, I expect to get a complete set of all Boost libraries of the
That's what I mean with three different versions of the library.
If that's not the case, then the levels of quality would just be a label
applied to a library meaning ... what?
> > - What is with bug fixes in the stable version? Wouldn't it take more
> > until a bug fix could finally be provided in the stable version?
> That's question is unclear to me
Regarding the explanation above, and then assuming that the bug fix changes
the interface in a non-compatible way: The bug fix could not be integrated
right away into the stable level of the library, right? Since it would make
the library 'not stable' anymore (due to the interface change)?
> > - What is if a library should be moved to the stable version, but
> > another (version of a) library which is not yet ready for the stable
> > version, or would brake the requirements for stable versions?
> That's easy: you can't depend on libraries in development to qualify for
> for production" status.
But that's exactly the point:
A new library can only get to the stable version, if all the libraries and
their versions it depends on are submitted to the stable version too.
Today you submit the library to the next release.
> > - I suppose a new library would be available in the stable version only 1
> > 2 years after it was released the first time? So if somebody wants to use
> > e.g. the forthcoming Boost Log library, he has to wait a long time.
> Why? It depends on you really. If you are willing to accept possible
> non-backward compatible changes or willing to stick to this particular
> or willing to maintain local copy yourself - you can use any library, even
Yes. So why should Boost need different levels of quality then?
If somebody can not accept backward incompatible changes, he simply sticks
to the version he was using initially. Otherwise he always uses the new
> Unsubscribe & other changes:
-- Dubito ergo cogito; cogito ergo sum. (I doubt, therefore I think; I think therefore I am) René Descartes