Boost logo

Boost :

Subject: Re: [boost] Stability: More on 3 level Boost libraries
From: Vicente Botet Escriba (vicente.botet_at_[hidden])
Date: 2010-03-26 06:36:11


Rene Eng wrote:
>
> 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
>> version
>> 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
> same level/quality.
>

Every one expect the other must do what we are not able to do :)
We are volunteers in the Boost community, and we do our best.

Rene Eng wrote:
>
> 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?
>
>

This was my intention. Just to put a label to a library that could guide the
final user about the stability/quality/mai_ntenability of the library

Rene Eng wrote:
>
>
>
>>
>> > - What is with bug fixes in the stable version? Wouldn't it take more
>> time
>> > 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)?
>
>

I'm not requesting for this level that there are no breaking changes in the
interface. I'm just that these change need to be reviewed by the Boost
community before been applied, to see if a non breaking solution exists.

What you require is not stability, but fix the interfaces. Sorry but I don't
think this is a good approach. If something NEEDS to be changed breaking the
user interface for a better library, we can not forbid such changes, we need
just to manage them.

Rene Eng wrote:
>
>
>
>> > - What is if a library should be moved to the stable version, but
>> requires
>> > 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
>> "ready
>> 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.
>
>
> Rene Eng wrote:
>>
>>
>> Forget the stable version. There is no a stable version, but stable
>> libraries.
>> All the libraries stable, quite stable and unstable will be released on
>> the same version. Just a library can change its label depending on the
>> criteria.
>>
>>
>
>> > - 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?
> If somebody can not accept backward incompatible changes, he simply sticks
> to the version he was using initially. Otherwise he always uses the new
> release.
>
>

The fact that a stable library can change its interface if really needed
doesn't means that this will occur often, otherwise the library will not be
stable, but can occur exceptionally.

Best,
Vicente

-- 
View this message in context: http://old.nabble.com/Stability%3A-More-on-3-level-Boost-libraries-tp27997145p28040616.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

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