Following up on this point made by Peter Dimov in another discussion:
This is part of the price you pay for being accepted as part of Boost - the duty to act as an integration test for your Boost dependencies. This is beneficial for you in the long term, because you can detect breaking changes in your dependencies before they get shipped. If you only test against 1.56, and 1.64 breaks your library, you won't hear about it before 1.72. This does you no good, and it does your users no good. You WANT to know if changes in 1.65's SmartPtr would break you BEFORE 1.65 gets released.
The real problem that you are touching here is Boost's lack of any sort of ABI or even API stability. So Boost 1.X and Boost 1.(X+1) are two distinct packages, as there is no metric that enables even to measure the amount of incompatibility between the two. Any normal library that's used in-production would have strong requirements for backward compatibility, to enable users to reason about the risk of upgrading etc. Thus, to follow up (and not pollute the original discussion about modularization), I'll propose the following: I'd like to see guidelines to be established for: * what API and ABI changes may be applied in a given release * have a clear definition of version numbers (major, minor, bug fix) with associated semantics * impose testing requirements to enforce the above. Stefan -- ...ich hab' noch einen Koffer in Berlin...