Cargo 1.33.0-nightly (0d1f1bbea 2018-12-19) only pulling the latest version

[RandomInsano]

Problem
Cargo seems to be ignoring the version asked for in Cargo.toml and is pulling the latest

Steps
Create a basic binary project, then add a dependency:

[dependencies]
cortex-m-rt = "0.6.5" ; Downloads 0.6.7 instead
serde = "1.0.80" ; Downloads 1.0.84 instead

Run cargo build:

Fauna2:test-cargo me$ cargo build
...
   Compiling serde v1.0.84
   Compiling cortex-m-rt v0.6.7
...

Possible Solution(s)

Notes
I can force it by changing Cargo.lock manually, delete the [metadata] section, but doing a cargo update brings it back:

    Updating crates.io index
    Updating cortex-m-rt v0.6.5 -> v0.6.7

Infos:

• cargo 1.33.0-nightly (0d1f1bb 2018-12-19)
• macOS 10.14.1

[ehuss]

This is normal. If a version does not have any operators, it is assumed to be a caret requirement. If you want to force a specific version, prefix it with =.

[RandomInsano]

Well, that's a new one. Confirmed that this makes things work out:

[dependencies]
cortex-m-rt = "=0.6.5"
serde = "=1.0.80"

When did this functionality change?

[ehuss]

I believe it has always been that way. Perhaps the Cargo.lock file has kept you at a specific version in the past. But whenever you run cargo update, the lock file will update everything.

[RandomInsano]

The issue here is that upstream, cortext-m-rt is no longer compatible with what is shipping in the Rust Embedded book.

I also don't fundamentally agree with how this works. I'd expect if I left off a minor version that it would be free to upgrade. For example, if my Cargo.toml looked like this:

[dependencies]
cortex-m-rt = "0.6"
serde = "1.0"

It would be fair game to go to the newer version. Now, the docs clearly show that updating would allow it, so this functionality is intentional. I guess I need to dig into both why "no operator means caret" was decided upon and why a specific version with "^1.2.3" would be allowed to play with version numbers and see if I can understand the rationale, because both seem like a bad ideas for backward compatibility.

[RandomInsano]

Okay, good news! I just never read the Semver spec and it seems the package I was using didn't follow it as they introduced a breaking change in a patch version instead of bumping the major number.