Huh, I didn't realize cargo did that. I think it behaves more like ~0.2 though, which matters more for semver-compatible ranges. For example, =1.0 will not update to 1.1 or later (but ^ would).

Do you have some example where this happens and where we do something wrong? I'm looking at this report, and I'm not quite sure what the request is.

The logic for some kinds of version requirements has always been a bit broken (in addition to supporting some kinds of operators that aren't even supported by cargo?) ... I think this should be fixed once we can switch to my rewrite (which I based on how the semver crate works, so it should match its behaviour, and in turn, the behaviour of cargo).

https://pagure.io/fedora-rust/cargo2rpm/blob/main/f/cargo2rpm/semver.py is what I'm currently working on, if somebody is interested.

This was fixed by the reimplementation of the parsing and evaluation of SemVer versions and version requirements in cargo2rpm:

$ python3
>>> from cargo2rpm.metadata import VersionReq
>>> req = VersionReq.parse("=0.2")
>>> req.normalize()
'>=0.2.0,<0.3.0'
>>> req = VersionReq.parse("=0.2.0")
>>> req.normalize()
'=0.2.0'