Re: [boost] Stability: More on 3 level Boost libraries

Subject: Re: [boost] Stability: More on 3 level Boost libraries
From: Andreas Masur (amasur_at_[hidden])
Date: 2010-03-25 19:36:09

On Mar 23, 2010, at 3:36 AM, vicente.botet wrote:

> Hi,
> 
> I would like to come back to the 3 level proposition but from a different point of view (stability and quality) 
> 
> 1st level: stable
> Libraries belonging to this level must be very stable, any modification on the public interface must be reviewed.
> The goal been that changes in these libraries don't break user code, even if they will need to recompile.
> Libraries can pretent to be in this level if the library use only libraries at this level, has not introduced breaking changes for a given amount of time and of course if the author wants to be constrained to have a review for changes on the public interface and to correct quicky the possible tickets.
> 
> 2nd level: quite stable
> Libraries at this level, even if stable, introduce breaking changes from time to time.
> Libraries can go to this level if the library use only libraries at this level or the 1st level, after a deep review of the of the interfaces, the documentation, the implementation and the test coverage and have a reduced number of tickets since a to be defined period.
> 
> 3rd level: unstable
> It is assumed that young libraries will have a lot of breaking changes at the public interface level. 
> Libraries can go to this level after a review of the interfaces and the documentation.
> 
> Comments are welcome,

Vicente,

First of all let me say that while I am following this list for quite some time, I still consider myself the quiet person in the background. There have been many threads lately about the current quality, situation, issues etc. with Boost - some with good ideas, some with unnecessary noise and discussions...at least from my point of view.

Now, I actually thought about your three-level approach and in general I tend to agree that Boost should incorporate a kind of dividing mechanism to make Boost somewhat easier to use for the "regular" developer. It is certainly questionable what a "regular" developer actually is but for the sake of the argument let's assume someone that does not live and breathe templates, metaprogramming and mind-bending tricks to satisfy the compiler.

If this developer sees a library that he actually could put to good use in his daily work, he should be able to use the library within a reasonable timeframe. This comes down to documentation which I do not want to discuss here. However, at the same time, he should be able to make the fair assessment that a newer version of Boost does not break his application due tom some change that may only be indirectly affecting the library he uses. From what I understand, this unfortunately still happens quite often which new releases. Again, 'quite often' is relative since I cannot put a number to it.

Based on the above, I like the initial idea of having different levels. What I am unsure about is whether or not diving these levels into stable/quite stable/unstable is

a) really clear enough
b) really keeps us from having arguments about the category a specific library should go into
c) may even make it difficult in general (e.g. what if a library is stable for 2 years but then brakes the interface and thus would be quite stable?)

I am usually a big proponent of the simple stable/experimental scheme. In my experience (and view) a library is always experimental in the beginning. Even the best design cannot cover all of the use cases initially. This is actually the phase where a library matures...in versioning speech, I consider these the 0.x releases. However, once a library is flagged 1.0, I do not consider it experimental anymore. At this point, the library is considered stable.

If breaking changes have to be introduced, I would rather like to see a "copy' of the library with the new "broken" interface as part of the experimental group again. In other words, the same library exists twice at this time: one in stable, one in experimental. This actually allows user to have the guarantee that a newer release of Boost does not brake their application, they can follow the evolution of the "updated" version of the library and they can even switch to it if they want.

Once the new library reaches its point where it gets closer to be considered stable, the original library can marked deprecated. At this point, developer can actually switch over to the new library (still under experimental) and integrate it. After a certain time, the library is then moved from experimental to stable thus replacing the old one. There are certainly variations possible of how to deal with the old and new library etc. but I think you get my initial point.

Again, I tend to like simplicity....having two categories that are at the very opposed ends of quality measures seems to be the most obvious in my eyes. Certainly, the policies of these two categories can be further discussed.

Well...this has become more lengthy than I anticipated.... ;)

Ciao, Andreas