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