Gennadiy Rozental wrote:
Hi,
Following David A. recommendation I put up a wiki page that presents initial version of my proposal for boost development environment, testing and release procedures.
http://svn.boost.org/trac/boost/wiki/IndependentLibraryVersioning
It's still missing one key piece - version selection algorithm. I just don't have time to complete it now and won't until weekend. But it should be complete enough to explain all the key points (and some more). I shamelessly stole couple statements from Beman's objective section. Well, we do have similar objectives ;)
Any comments are welcome.
I like the idea of allowing individual libraries and their dependencies being released between full Boost versions when deemed necessary. However, from an end user's point of view, allowing a version of some library to be released with an earlier dependency version than a version of another library with a later dependency version, where the first library no longer works with the later dependency version, will be a nightmare. Because of that I believe that any individual library needs to be co-ordinated with its dependencies so that changes in a dependency library, which may be released on its own or with another library, does not break the original individual library. When I say "break" the original individual library I am not speaking about a bug which may occur in a dependency but rather a change to the public ( or protected ) programming interface of the dependent, which I will call, perhaps erroneously, the ABI. The reason I think such a situation will be a nightmare to end-users is because an end-user may then have more than one version of the same dependency library within the structure of using a general Boost release, and pointing to a different set of header files, with possibly the equivalent libraries files for non-header-only libraries, for each different use of the libraries, will create great logistical difficulties to the smooth use of Boost. As an example, suppose I use library A and library B, both of which have library C as a dependency. Library A uses version 1 of library C and library B uses version 2 of library C. Library A is broken, ABI-wise, with version 2 of library C. Now I want to use both library A and library B in my program ( or module ), often from within the same source file compilation. How in the world do I have library A pointing to its own version of library C's header files while library B points to its own version of library C's header files ? This can be complicated further if library C has lib files which either statically are added to my module or are linked to dynamically through a shared library. This situation just increases the nightmare of trying to use both the libraries. As I suggested in another post on this thread, I think it is certainly possible for an individual library to be released between full Boost releases, but only if the Boost developer of that library makes sure that his library is always co-ordinated ABI-wise with any of its dependencies. Likewise if a dependency of a library is going to be released itself, it is imperative that any libraries for which that library is a dependency, and for which the change to the dependency will create an ABI problem, also be released with an update at the same time which fixes the ABI problem. It is nice to think that any Boost library should be able to be released at any time to work with any version of a dependency, but the reality of such a plan will often lead to chaos from the end-user's point of view. I am not saying this can not be done for unique individual situations, since I have done it myself using the Boost regex++ library, but it needs very careful consideration so as not to create a nightmare for the end-user.