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 16:06:15

Stefan Seefeld wrote:
> Thomas Klimpel wrote:
> > Stefan Seefeld wrote:
> >> Wait. You'd like to have releases bundle both, and you don't want to
> >> provide distinct guarantees. What's the point in this split, then ?
> > 1) To make the life of package maintainers (e.g. debian, ubuntu) easier.
>
> I still don't see what change they would see.

You may be right that it is difficult to know the exact impact for package maintainers. Remember that my initial reply was to a package maintainer that mentioned the release frequency of boost, and that I asked why not reduce the frequency to two major releases per year. There are some linux distributions that also release two times per year, so it could indeed help them. I'm also not sure how boost is currently packaged in debian, but I believe having seen packages which didn't installed boost as a huge blob, but had a finer sub-package structure.

> > 2) To make adoption of boost in corporate environments easier,
> > by offering the option to only use the "core" package, potentially
> > cherry-picking only a few of the other libraries from the "complete" package.
>
> "from the complete package" isn't an option. Either I can obtain
> official stand-alone packages or I can't.

So dependencies between the libraries not in the core package would have to be documented (and the actual dependencies would need to guaranteed to really be not worse than documented). Packaging the release for distribution into "core" and "complete" doesn't mean that cherry-picking packages from the complete set is not official supported. You could have a Boost.Build option that installs you a library including all it's dependencies into a certain location.

> accidentally stable ("stable without any explicit guarantee") is only
> marginally better than unstable. It still means one has to re-validate
> everything for each version, and a 'drop-in upgrade' is probably impossible.

It's a bit the same as with the warning-free compile. The maintainers would strive to keep it stable. Even if you would be guaranteed that it is stable, that still wouldn't imply that you could be completely sure of this.

But it was just a suggestion, and I got the message that it won't solve the problems you see.

Regards,
Thomas