Suppose I have a library crate which uses openssl 0.7. The library crate has version 1.0. I want to update my openssl deps to openssl 0.9. It is not a breaking change of a crate but it may cause problems for the users. So should I change the version of my crate to 2.0 after that?
If there’s a risk it will break things for your users, then it’s a good idea to bump semver-major. Numbers are free and plentiful.
But If I need to do that everytime the crate’s version will be 10.0.0 in just about a year. (It depends on the dependencies actually).
Then only update dependencies when you need to.
If the dependencies don’t cause breakage, then you don’t need to bump major version of your crate. You can update minor versions of your dependencies at any time. If a dependency is completely abstracted away and not exposed as part of your interface (i.e. you don’t re-export any types) and dependency’s reason for breakage is irrelevant for users of your crate, then it’s fine to update dependency major version, too.
But AFAIK openssl does break its API/ABI and shouldn’t be linked more than once in a program, so it is helpful to guard your users against unexpected openssl mixups with semver-major bump.
If during a year you change openssl 10 times in significantly incompatible ways, then ending up with v10 is absolutely correct.
Semantic, rather than sentimental versioning isn’t meant to reflect how mature/advanced/stable/big your project is. It just bumps otherwise meaningless numbers to guide updates. v537.36.0 is a perfectly fine semver version number.