One of boosts roles is to do research and development, the other is to establish existing practise. The R& D role inevitably results in the need to break an existing interface in the interest of providing a better one, however that is inevitably not going to go down well with existing users. Establishing existing practise demands a high level of stability. Perhaps there needs to be a clear policy on the procedure to follow to go about modifying the interface ...
There has been talk about splitting boost into more manageable chunks for a long time and that seems to an ideal split line: stable: interface will never change; only bug fixes in future experimental: interface may change in a subsequent release Requirements for stable could be: no changes in at least 6 months and author(s) having no intention to make changes. If an author wants to make backwards-incompatible changes to a stable library they make it a new library, with a new name (even it just tacking "2" on to the end of the existing name). This should of course happen very rarely. Having a stable core will give developers more confidence in using boost for important projects; I think it is essential. Darren