Boost logo

Boost :

Subject: Re: [boost] Stability: More on 3 level Boost libraries
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2010-03-26 05:29:23


Rene Eng <gemini67 <at> gmail.com> writes:

> 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
> same level/quality.
> That's what I mean with three different versions of the library.

Boost is not a library.

> If that's not the case, then the levels of quality would just be a label
> applied to a library meaning ... what?

meaning that some boost components are stable, some in development.
 
> 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)?

You can make any *backward compatible* change to the stable library IMO. And you
can't make non-backward compatible changes to the stable library period.

> 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.

Each Boost component has it's own life cycle. Presence library in boost release
does not make it stable.
 
> > > - I suppose a new library would be available in the stable version only 1
> > or
> > > 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
> > version
> > or willing to maintain local copy yourself - you can use any library, even
> > just
> > candidate.
> >
>
> Yes. So why should Boost need different levels of quality then?

User need to know if library is in development of is stable and can make
decisions as to usage based on that.

Gennadiy


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk