# Adding compiler version to dependency resolution **URL:** \ **Category:** Uncategorized\ **Created:** [August 16, 2019, 8:32pm UTC](https://internals.rust-lang.org/t/adding-compiler-version-to-dependency-resolution/10795 "2019-08-16T20:32:06Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![elichai2](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/elichai2/32/5205_2.png) [@elichai2](https://internals.rust-lang.org/u/elichai2)\ **Post date:** [August 16, 2019, 8:32pm UTC](https://internals.rust-lang.org/t/adding-compiler-version-to-dependency-resolution/10795/1 "2019-08-16T20:32:06Z")
Hi, As rust tries to become more and more stable there's an important feature in any stable compiled language that aims to be a system language, Stability. This requires 2 main things: 1. That the code I wrote a year ago still compile with the latest compiler(latest in the same major version). 2. That the code I wrote a year ago still compile with the same compiler I've used (i.e. a compiler that was audited / air gapped approved by some regulation) The first requirement is already pretty good while the second one is currently a disaster. Most of the ecosystem assumes you're always updating your compiler and allow themselves to increase compiler requirements in minor version bumps. I'm not saying this is necessarily bad practice, But I'm suggesting to add minimum compiler version to `Cargo.toml` such that the compiler can take that into account when resolving dependencies, and if there's version X.Y.Z but it doesn't support the used compiler it could check X.Y.Z-1 etc. ---
**Author:** ![cuviper](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cuviper/32/1897_2.png) [@cuviper](https://internals.rust-lang.org/u/cuviper)\ **Post date:** [August 16, 2019, 8:34pm UTC](https://internals.rust-lang.org/t/adding-compiler-version-to-dependency-resolution/10795/2 "2019-08-16T20:34:56Z")
There have been a few RFCs to specify the required compiler version, but none have real traction yet. > [@elichai2](#): > > 1. That the code I wrote a year ago still compile with the same compiler I've used (i.e. a compiler that was audited / air gapped approved by some regulation) The best answer for this is to keep your `Cargo.lock`, so you're compiling with _all_ of the same code. Maybe even use `cargo vendor` to preserve all of those dependencies locally. ---
**Author:** ![Ixrec](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ixrec/32/6754_2.png) [@Ixrec](https://internals.rust-lang.org/u/Ixrec)\ **Post date:** [August 16, 2019, 9:43pm UTC](https://internals.rust-lang.org/t/adding-compiler-version-to-dependency-resolution/10795/3 "2019-08-16T21:43:38Z")
First, point #2 in the OP post is pretty vague, and on some plausible readings it's already a solved problem: either hang onto your `Cargo.lock` file or `cargo vendor` all of your dependencies. But there's certainly other plausible readings that include all the usual motivations for minimum Rust version, which are probably at least part of what OP was after. This [nerd-sniped](https://xkcd.com/356/) me into following the whole web of links to past discussions on the subject, so here's what I think are the most interesting and/or relevant things out there: - It's worth noting that you can do version detection within your own build (by using a `build.rs` to call `rustc --version`, which is even automated for you by the `version_check` crate). That doesn't affect how Cargo resolves versions for all your dependencies, but it can at least be used to stop an older `rustc` from even trying to build your code. - Proposals to make cargo aware of minimum supported Rust versions go back to well before 1.0, and back then were mostly rejected on the grounds that it should be a post-1.0 thing. Of course, there were multiple proposals after 1.0: [#1707](https://github.com/rust-lang/rfcs/pull/1707), [#1709](https://github.com/rust-lang/rfcs/pull/1709), [#1953](https://github.com/rust-lang/rfcs/pull/1953), and [#2182](https://github.com/rust-lang/rfcs/pull/2182) that I could find. To vastly oversimplify all of that discussion, it turns out specifying this feature is a lot more complicated than you'd think, and most iterations got bogged down in what retrospectively feel like tangential concerns. The most common trap seems to be trying to version cargo or Cargo.toml in addition to versioning rustc. - The best explanation of why this is actually a hard, still-unsolved design problem and not "just add the Rust version to `Cargo.toml`" would be [@aturon's "Version selection in Cargo" blog post](http://aturon.github.io/tech/2018/07/25/cargo-version-selection/). Probably the most important takeaway is that this is as much a social problem as it is a technical one. - The [RFC for LTS (long-term support) releases](https://github.com/rust-lang/rfcs/pull/2483), which was originally envisioned as a solution to this problem because we could agree as a community that the LTS version was the one all crates had to support. It was ultimately closed for a variety of reasons [best explained by @ag\_dubs's comment](https://github.com/rust-lang/rfcs/pull/2483#issuecomment-404630877). - The latest RFC for actually doing this: [Minimum Supported Rust Version](https://github.com/rust-lang/rfcs/pull/2495). - Finally, a tangent, but IMO the most interesting one: Is increasing a crate's minimum Rust version a semver breaking change for that crate? [This urlo thread](https://users.rust-lang.org/t/rust-version-requirement-change-as-semver-breaking-or-not/20980) was an excellent exploration of that question. ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [November 14, 2019, 9:53pm UTC](https://internals.rust-lang.org/t/adding-compiler-version-to-dependency-resolution/10795/4 "2019-11-14T21:53:41Z")
Closed on November 14, 2019, 9:53pm UTC This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.