IMO stable = stale.
I would hope that all boost libraries would be constantly evolving.
I am not sure if you read my post but the two concepts are not mutually exclusive. I expect you wouldn't be too happy if the next release drastically altered the behaviour of shared_ptr, yes? I would like to have some warning and perhaps a transition period. I think the "stable" libraries are well established and rarely change anyway - and that's the user's expectation, too. Hence if they were to change drastically, it would take people by surprise. I was trying to suggest that when changing them, it should be done with more care than for some of the newer libs, which would be allowed more flexibility. The second part of what I'm saying is, IMHO, applicable to any large corporate environment. You really want to use a newly accepted/released library X but you can't, because your firm is stuck on boost version neanderthal. If new libraries could be released in incremental releases that don't necessarily alter the core components of boost, it would be much easier to introduce them to such environments. Each new version of boost means rebuild the world and that's not feasible, unless it's also part of some major internal release. Furthermore, now you've introduced several new variables into the new build and limiting the number of moving parts is IMHO a good idea. These internal rebuilds don't happen too often, and this in turn is giving new boost libraries less exposure than they could have. There were a few other reasons I wrote about in the link provided but the two above are the major ones. Tom