Cargo's semantic versioning-based dependency resolution is one of the most important parts of why it works so well as a package manager.
The below examples, from the Cargo Book, demonstrate how this dependency resolution logic works in concrete form.
1.2.3 := >=1.2.3, <2.0.0 1.2 := >=1.2.0, <2.0.0 1 := >=1.0.0, <2.0.0 0.2.3 := >=0.2.3, <0.3.0 0.2 := >=0.2.0, <0.3.0 0.0.3 := >=0.0.3, <0.0.4 0.0 := >=0.0.0, <0.1.0 0 := >=0.0.0, <1.0.0
This model enables robust, yet flexible version specification:
Cargo will fetch upgrades beyond the literal stated version, but only up to a maximum range
Versions ranges are variable by specificity. When a dependent crate's interface is tightly integrated into the code, a tight version range can be used, if the dependency is loosely integrated, a wider range can be used. This provides flexibility
In practice, adherence to semantic versioning guidelines is consistent enough in the crates published to Crates.io that it provides meaningful tiers of change severity. In other words, You can generally rely on it.
Not all methods of specifying dependencies utilize the semantic versioning-based dependency resolution. For example, path-based and git-based dependencies do not have any built-in notion of version, so Cargo does not have any means of applying this logic to its upgrade decisions for those dependencies. This is a key drawback of path- and git-based dependencies that is sometimes neglected when considering the pros and cons of different approaches.