> I'm not sure that I see this as a CL-specific problem. If you have a C++ program that uses one boost version and it uses a library that requires a different boost version, you have the same problem.
>
> I also don't think that this is a problem with semantic versioning: the boost people use what we might call "anti-semantic versioning," but they still wreak havoc with the world. The problem isn't that semantic versioning breaks everything, the problem is that different libraries evolve at different rates, and that causes stuff to break.
>
> I would argue that this shows the *strength* of semantic versioning: no, it doesn't magically solve the problem of version skew, but in at least some cases it tells you that you have version skew, and tells you where to look for a solution, instead of leaving you flailing around trying to figure out why your code has suddenly stopped working.
My personal experience is that semver is of no help because 1) authors don't really know when or how to increase the number, most have adopted semver because it's fashionable and 2) the users don't really know what the true minimum version is and just winge it by selecting whatever recent version they're working with as minimum requirement.
In the end both the release version and the dep versions are nothing more than suggeestions and the only sure way to know if integrating N libraries works is to try to load them all together and run their own test suites plus your application's test suite.
I'm not sure how this is related to dependency declaration support in general: if you truely believe the information in the dependency declaration to be worthless, then there's no solution other than have everybody figure out their own dependency chains for themselves.
But if you're not going to use the information, then what are you objecting to?