Is cargo intended to act this way, or it a bug?

help
5 
    Updating crates.io index
    Updating cc v1.0.71 -> v1.0.72
      Adding cfg-if v1.0.0
    Updating cmake v0.1.46 -> v0.1.48
    Updating libc v0.2.104 -> v0.2.112
    Updating raylib v3.5.0 -> v3.7.0
    Updating raylib-sys v3.5.0 -> v3.7.0
warning: not updating lockfile due to dry run

I see that this output fits with the notion that this is just the crate not following semver.

Starting after Step 2 above, I changed the version from "3.7" to "~3.5.0". I then get a different set of compile errors. This time they originate in the crate's code in my .cargo folder.

Here's one of the errors:

error[E0560]: struct `raylib_sys::NPatchInfo` has no field named `type_`
  --> /home/ryan/.cargo/registry/src/github.com-1ecc6299db9ec823/raylib-3.5.0/src/core/texture.rs:43:13
   |
43 |             type_: (self.type_ as u32) as i32,
   |             ^^^^^ `raylib_sys::NPatchInfo` does not have this field
   |
   = note: available fields are: `source`, `left`, `top`, `right`, `bottom`, `layout`

It seems to me that this case is still some sort of bug.

I had tried some different syntaxes for setting the version before, too, and I saw these same errors at that time, but I forgot to mention them in the first post. I can see now that leaving that part out gave the wrong impression.

FWIW cargo update --dry-run only outputs the following in this state with the library errors:

    Updating crates.io index
warning: not updating lockfile due to dry run

Going from a point where it compiles, (step 1 or 5) and then changing it to "~3.5.0" results in the following output from cargo update --dry-run:

    Updating crates.io index
    Updating cc v1.0.71 -> v1.0.72
    Updating cmake v0.1.46 -> v0.1.48
    Updating libc v0.2.104 -> v0.2.112
    Updating raylib-sys v3.5.0 -> v3.7.0
warning: not updating lockfile due to dry run

But if I run cargo r the program builds and runs.

So, in summary, I think pinning the version makes sense, and I am now less confused. But I think the state where the compile errors come from the library is still a state that should not be reachable. Does that statement seem correct, or have I misunderstood/forgotten something else?