This is a surprising feature of the Conan C++ package manager: It allows to specify dependencies of packages, and also to specify ranges of dependencies, but it does not provide any way to automatically resolve them. The responsibility for the resolution is with the resulting application at the top of the graph, it has to provide version numbers or ranges for all conflicting dependencies, regardless how deep thy are in the dependency graph.<p>Here some more information:<p><a href="https://docs.conan.io/en/1.22/versioning/version_ranges.html?highlight=joint-compatibility" rel="nofollow">https://docs.conan.io/en/1.22/versioning/version_ranges.html...</a><p>See also:<p><a href="https://github.com/conan-io/conan/issues/9547" rel="nofollow">https://github.com/conan-io/conan/issues/9547</a><p>I think dependency resolution in systems of networked software is a tough problem, and I believe there is only one solution that will scale well enough: Requiring strict backward compatibility on every level.<p>If you think that there is another way, consider this:<p>Application A requires dependencies D1.0 and E1.0. Both D and E require a library L1.0 , thus we have a "diamond dependency structure". And as it is C++, let's assume that L is either dynamically linked, or has versioning requirements that are visible outside, for example data formats.<p>Now, L1.0 makes a breaking change, and, not following semantic versioning, labels the new version as L1.1. This could be a library like boost, which is used by many thousands of applications.<p>Now, let's assume that D1.0 has an urgent security vulnerability (may be it is related to logging ?) and ships a new emergency release D1.1, which happens to use L1.1. And let's assume that D is well tested with that. But the incompatible change in L1.1 happens to break E. And this means that application A cannot be upgraded, unless E is adapted to L1.1. And the net effect is that the breaking change in L1.1 causes a breaking change in D1.1, because the change in D breaks A. Nothing is achieved by shifting the blame for that to A that it uses such an old library L1, it is still the change in D that breaks A, so *D is not backwards compatible*.<p>The corollary is that <i>if your library D includes another library L as a dependency which introduces a breaking change, and that library is visible to the outside (that is, not statically linked and only internally used), then the breaking change in L causes a breaking change in your library D</i>. This means that being backwards incompatible is a transitive property - you only achieve backwards incompatibility in a system if every relevant part of it is backward compatible.