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

Subject: Re: [boost] Stability: More on 3 level Boost libraries
From: Rene Eng (gemini67_at_[hidden])
Date: 2010-03-26 00:49:13

Hi

My name is René Eng and I am a team leader in the SD departement. We are
programming in C++ and plan to use Boost in the next release of our product,
already use some parts already (Boost.Test, Boost.ProgramOptions).
I also tried some things from Boost at home, especially Boost.Interprocess.
There I did encounter myself the effect that my programs did not compile
anymore with a new version of the Boost library.

So I look at the '3 level proposal' from a user side of view.

While at first glance it seems a good thing, that you can download the
stable version and don't worry, I see a lot of dangerous points in there for
the boost development community:
- You have to maintain 3 sets of the Boost library that are in itself
compatible.
- 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?
- 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?
- 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.

I don't mind that one Boost library uses another (of course: code reuse!).

For me as a user, I am happy if the library compiles on my platform and all
regression tests run successfully. And i the regression tests cover about 95
% of the code and functions, I am very happy and confident that it will
work.

If we will use Boost, we will write PIMPL like wrappers anyway, so that
changes in the interface of a Boost library will of course require code
changes on our side, but only in specific modules, the rest of the
application should then be unharmed.

Please think through all the advantages and potential problems of
maintaining multiple library versions. If you find a good definition that is
easy to maintain and really brings advantages to the end user: go ahead.

Regards,
René

P.S.
We are dealing with currently 3 different versions of our application used
by our customers, so I have some experience with maintaining multiple
versions.

-- 
“Dubito ergo cogito; cogito ergo sum.
(I doubt, therefore I think; I think therefore I am)”
René Descartes