Rust version requirement change as semver breaking or not


a bug in which compiler, though? I can imagine both:

  • rustc N compiles the code, rustc N+1 does not because of a new bug
  • rustc N compiles the code due to a soundness bug, rustc N+1 does not because of a fix.

I think there have been examples of both, if only edge cases.


Deprecating doesn’t mean removal, so that shouldn’t affect things.

That’s not the usual chain of events for deprecation in other languages. If true, it should be better spelled out for rust. And, I’ve already run into what looks like a counter-example… the removal of char_at (deprecated in 1.9 and removed in 1.11).

It’s discussed in the rust-lang/rust#46942 issue.

Historian’s note: char_at was deprecated in 1.9 (552eda7) and removed in 1.11 (b64c9d5).
- @zackmdavis

Was it not really removed?


It was never there to begin with. Unstable APIs are unstable, so they can be removed.

If a stabilized item is deprecated, then it’s never removed. This has always been our policy and was spelled out in the API evolution RFC: — That is, removal of any API item is treated as breaking change requiring a major version bump.


As a related FYI, I made a script a few weeks ago to find out the earliest MSRV for a project: which helps when transitioning a project with no stated MSRV to having a stated (and ideally CI-tested) one.

One of the reasons why many of my projects don’t have an MSRV is because I never bothered to set one up. Sometimes that’s not an issue, as these aren’t used a lot anyway, but sometimes it is, and this tool was so I didn’t fall in either of:

  • setting the MSRV to the latest, because that’s what my dev machine has; or
  • ever-delaying setting an MSRV because I don’t want to spend a lot of time manually testing N versions backwards.

Thought it might help others :slight_smile: