It's really annoying when you think you push a semver-compatible update to a crate (for example, updating regex from 1.4.x to 1.5.0) only to discover that somebody thought it was a good idea to restrict their regex dependencies to version ~1.4 (i.e. >= 1.4.0; < 1.5.0).

This might be well-intentioned by upstream developers, but the only reason they might do something like that is either 1) misunderstanding of SemVer or cargo behaviour, or 2) using this restriction to keep supporting older versions of Rust.

Both are not valid reasons to keep ~ version restrictions in our packages, which is why I've started to remove them when I encountered them.

As far as I can tell, using ~0.5 and 0.5 (or ^0.5) is equivalent, but using ~x.y (for x >= 1) is a useless restriction for RPM packaging purposes, which only causes accidental breakages when somebody pushes a SemVer compatible update they thought to be safe.

Additionally, there's no way (or sense) in packaging i.e. both regex versions 1.4.x and 1.5.x as separate packages. Neither our tooling nor our policies consider this a valid - or necessary - thing to do.

Would it make sense to add something like this to the Rust Packaging Guidelines?

If a crate's Cargo.toml file contains dependencies with a ~ version restriction, this MUST be removed, as the reasons to use the ~ restriction are, in almost all cases, not valid for Fedora packages (for example, the need to stay at an older MSRV).
Tilde-style specifiers like that cause problems when pushing otherwise non-breaking, SemVer-compatible updates for the affected crates, because they are stronger restrictions than those required or guaranteed by SemVer.

And then we can make rust2rpm print a warning if a crate uses ~ version specifiers that haven't been patched out.