Rene Eng wrote:
2010/3/26 Gennadiy Rozental <rogeeff@gmail.com>
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-tp2799714... Sent from the Boost - Dev mailing list archive at Nabble.com.