Re: [boost] Core libraries should separated from experimental libraries

Subject: Re: [boost] Core libraries should separated from experimental libraries
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-11-22 07:13:16

Stefan Seefeld wrote:
> Thomas Klimpel wrote:
> > Why not? 2 releases/year doesn't sound that bad to me.
>
> I think the fundamental issue (as far as boost.org is concerned) is not
> the number of releases, but their relationship (or in fact, the lack of
> relationship, as it stands) to each other. Without any kind of API or
> ABI compatibility guarantees (or even promises), I have to consider two
> distinct boost releases as two entirely different products.

I have different reasons why I think reducing the frequency of major releases could save some work for different parties.

There are some libraries in the sandbox already in active real world use, even so they still have a long way to go before they are ready for a formal review request. In my case it is the numeric_bindings library, but there are many more libraries of this sort. Among others, numeric_bindings depends on Boost.uBlas, which is probably not a "core" library in your view of the world. It's regression tests also depend on Boost.Build. Having to run regression tests against a number of released boost versions in addition to running regression tests against a number of blas/lapack implementations compiled with different fortran compilers is less funny and more time consuming than it looks from the distance. And yes, there were issues, Boost.Build changed incompatible from 1.33 to 1.34, there was a minor bug in 1.35 in a boost library numeric_bindings depended on (sorry, I don't remember exactly which, but I could look it up if it is important to you), there were changes in uBlas that forced some updates to numeric_bindings library, even so it was possible to update it without breaking compatibility with older boost releases.

The situation for Glas (Generic Linear Algebra Software) was probably still worse, because it depends in parts on Boost.Numeric.Bindings. It ended up directly including Boost.Numeric.Bindings in its repository, in order to not completely confuse its users. I don't know about the situation of mtl4 (matrix template library), but it also depends on Boost in some way.

And I don't think that these numeric libraries are the exception. For example, Boost.Asio was already widely used before acceptance into boost, and the dependence on Boost.Serialization at least caused some nontrivial issues, even if they were no showstoppers in the end. Boost.Cmake decided to mirror the complete release branch to resolve its issues, but this approach doesn't scale to more than one external project.

> Try to look at it that way, and you may understand the concerns I'm
> talking about.

I don't know whether I understand your concerns. I'm just not sure that it will be easy to agree on a set of core libraries. If it were just the official boost libraries themselves, it would at least be easy to figure out which library must necessarily be considered as "core". But you will never know exactly which boost libraries are used by closely boost related projects, like the libraries in the sandbox. For them, the official release boost libraries present the "core" libraries, and the other sandbox libraries are the experimental ones (and as Glas shows, it is quite possible that there is even a dependence to another experimental library).

> Again, the context of this discussion is "core libraries". I can
> definitely see the lack of appeal in any sort of compatibility guarantee
> for highly experimental code. If boost.org started to use a modular
> approach (even if only as a mental model), may be at least the most
> widely used boost components could become "stable" in this sense.

But I think the need for testing with the different releases would not go away. It would even grow, because there would be more combinations to be considered during testing.

Regards,
Thomas