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:
That the code I wrote a year ago still compile with the latest compiler(latest in the same major version).
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.
There have been a few RFCs to specify the required compiler version, but none have real traction yet.
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.
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 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, #1709, #1953, and #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. Probably the most important takeaway is that this is as much a social problem as it is a technical one.
9 days ago, there was a new comment on that RFC thread about the Cargo team's current thoughts. AFAICT, this is the latest "news" on the subject.
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 was an excellent exploration of that question.