Compiler version support breakage in semver



Recently I was made aware of the issue in one of my crates where it wouldn’t compile anymore with a fairly weird error, despite crate not receiving any changes since it has been initially written. Turns out the person was using a fairly old version of rustc 1.17.0 (e.g. provided by distribution packages).

The situation occurs with a Cargo.toml as follows:

clap = "2.23"

cargo today picks a sem-ver compatible version of clap =2.29. However somewhere in between version 2.23 and 2.29, clap upgraded its bitflags dependency from 0.8 to 1.0. bitflags=1.0, however, requires rustc 1.20 to compile, and so the crate dependent on clap ^2.23 cannot compile with rustc 1.17.0 anymore, even though it could compile fine before.

Where should the responsibility fall here?

Should clap have bumped the major version when releasing a version which (indirectly) drops support for older versions of rustc? Should the crate depending on clap in the scenario described above specify =2.23 instead of ^2.23?

If former, then clearly community isn’t being sufficiently meticulous when bumping dependency versions and we should educate (… evangelise?) maintainers better. If latter, won’t we essentially lose most of the benefits semver brings us in the first place? Is there an unambiguous answer?

I remember there was some chatter regarding this in the past, but not sure if any conclusion was arrived to.

cc @steveklabnik @kbknapp

Cargo seems to ignore version of dependency

My impression has been that opinions differ about this and there is no consensus, there’s good arguments for either choice. For example many authors want to be able to gradually drop support for older Rust without major bumps.


Check out this thread for a thorough perspective from both sides.


I agree in a perfect world upgrading minimum rust should be a breaking change and require a major version bump. However, with Rusts rapid 6 week release cycle and nursery/official crates only supporting current stable minus two (officially, even though in practice its far more conservative) it makes it difficult.

I would like to see more discussion on the matter and some guidelines. My fear is when advocating both rapid releases of the compiler and upgrading minimum required compiler versions is a breaking change, that it encourages crates to stay pre 1.0 thus effectively negating semver anyways.


Hey. We had this same issue in another language. The conclusion is that updating a dependency isn’t a breaking change (iirc it is mentioned in the semver spec)


Semantic versioning doesn’t really require anything past API compatibility, and it doesn’t specify exactly what is a part and what isn’t of API compatibility. At least as far as I’m aware of.

One could argue that compiler version support is a component of public interface provided by a library, and I could as well see somebody arguing that it is not.

Thanks for referencing this issue!


This is from semver


That doesn’t say whether “public API” includes the compiler version or not, which I think is what @nagisa’s point was. Even if you don’t like that particular formulation, the problem itself doesn’t go away. semver is a means to an end, not an end itself.