Boost logo

Boost :

From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2006-01-26 10:18:39


On Jan 26, 2006, at 5:58 AM, Paul Baxter wrote:
> While on the subject of releases, it has been mooted that perhaps
> Boost
> shouldn't be released as one monolithic package and that the
> problem might
> be better tackled by a finer grained approach and having a two-tier
> release
> management structure. Individual 'modules' are released upwards (and
> available as versioned outputs) and a main boost release is simply a
> collection of latest inter-operable set of versioned modules.

The problem with a fine-grained approach is that all of the grains
have to fit together. We have to manage version dependencies between
the components (e.g., to deal with breaks in backward compatibility),
and deal with user problems that arise from mismatched component
versions. We'd have to push our overly-taxed regression testing
systems harder to cover various collections of modules.

I'm not completely against the finer-grained approach, but I've seen
enough problems with it in other projects to cause some concern. Have
you ever maintained a Linux system using Gentoo? It's nearly
impossible to duplicate (and, thus, diagnose) errors from one system
to the next, because nobody has exactly the same set of components.
Often, compiling a new component will break because of some minor
incompatibility with another component, forcing you to roll back
something. Cygwin has the same issue, although the problems there
usually result in weird instabilities due to misunderstood
interactions between different versions of the components.

Where has the fine-grained approach worked well? How can Boost
duplicate their model to successfully deploy a more modular Boost?
How much effort would be involved both in the conversion and in
maintaining the resulting modular Boost? I could spew more questions,
but my underlying question is much more broad: While component-
oriented systems work wonderfully on paper, I've seen far more
failures than successes, and I'd like to see why we think Boost can
get itself into the latter category.

        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk