| Back when I used to manage libraries that were required and required other libraries, I only ever really "knew" when particular version of a dependency didn't work. Do you ever really know that something works? No, there may always be a bug, some way things interact poorly. From a maintainer's point of view there are things like: 1. Probably this dependency version works, because I have no reason to believe otherwise 2. This dependency existed at the time I released a version of my library 3. This dependency existed, and I used it during testing and development 4. This dependency is co-maintained, so future versions of the dependency are likely to be compatible per semantic versioning 5. My library means nothing to this dependency, and they may or may not break it based on their whims 6. We don't really talk, but if there's an issue whoever you tell first may well fix it 7. I will release dot-releases to make sure future versions of the dependency are supported 8. I have specifically confirmed certain versions of my library and the dependency are incompatible Most of these assertions are social and incomplete. Assuming a version, once released, is never changed or retracted, then one of the few firm guarantees you can declare is incompatibility. Declaring compatibility doesn't make it so, it only indicates a desire (and it's not even clear whose desire). On top of that, compatibility should really be more like metadata, not included in the package. Compatibility and incompatibility is a discovery process (along with security). In practice it's fine though, because it's ultimately the integrator (the person making some actual application) who has the responsibility to ensure everything works together. |