Subject: Re: [boost] Core libraries should separated from experimental libraries
From: Steve M. Robbins (steve_at_[hidden])
Date: 2009-11-21 09:34:17
I am on the Boost packaging team for Debian linux.
On Fri, Nov 20, 2009 at 01:55:59PM -0500, Stefan Seefeld wrote:
> On 11/20/2009 12:48 AM, Tom Brinkman wrote:
[ ... ]
> >If "average" developers happen to find boost useful, of course they can use it,
> >but they need to appreciate where boost priorities have been and use
> >it appropriately.
[ ... ]
> A much bigger issue I see with industry acceptance is code stability
> (not in terms of bugs, but in terms of backwards compatibility),
> scalability (boost is growing bigger and bigger, and very few people
> seem to care about how sustainable this growth is. It's just not
> true that boost users only pay for what they use), or
> maintainability (what if I need a bugfix from boost-1.(x+1), but
> without loosing compatibility with boost-1.x ? What about packaging
> issues ? I build software that runs on a wide variety of platforms,
> so the nightmare of figuring out the platform-specific boost
> dependencies and build issues for all of them is all mine.)
Indeed, "What about packaging issues?"
From my point of view, as part of the Boost packaging team for Debian
linux, 4 releases/year is killing me. Debian releases on a 1.5 - 2
year cycle, so we spin through 6-8 Boost releases between stable
Debian releases. Other linux distributions, although they release
faster, experience similar churn.
At this point, let me be perfectly clear: I'm not asking Boost to slow
down the release cycle.
But let's understand what this rapid release does to the various
distributions (linux, BSD, whatever). With no guidance from the Boost
maintainers, we will take whatever Boost release is current at the
time we freeze. This is the version that is in the field for the next
2 years or so. Ubuntu will do the same, but because they freeze at a
different time, often it is a different version of Boost. Same for
Red Hat, & etc. This contributes to the nightmare that Stefan
What can be done? Part of the issue is the disparate release cycles
between the various distributions. This has been described at
length by Mark Shuttleworth  and there seems to be some movement
in this direction between Debian and Ubuntu . The action here
is on the distributions.
Assuming this can be solved, what can Boost do? One thought is that,
if Boost knows that a particular version will be in the field for 2
years, that there could be some maintenance releases done to fix
issues with updated compilers or what have you. A lot of such things
seem to get fixed in trunk and not propagated to release for some
time. Another thought is that mature "core" boost libraries that
don't change rapidly could be separated and released on a slower
I'd like to hear the thoughts of the Boost release managers to this
kind of thinking.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk