This is one of the biggest problems I've had with any neat Rust thing posted up here. The language changes a lot. I have rust/cargo 1.37.0 installed (it's the latest marked stable in Gentoo) and adler32 v1.0.4 fails to compile with "`core::slice::<impl [T]>::len` is not yet stable as a const fn". I'm installing 1.40.0 from the unstable tree to see if that will build it.

I've had situations where I'm either not on the latest version of rust, or I'm on too current a version of rust, which deprecated/removed some feature needed for a dependency. I'm not sure if devs can define their min/max versions, but that kinda check should probably be done before cargo starts building packages.

Agreed, and I had the same problem. It seems like an easy fix to add a requires_rust_version thing in Cargo.toml, and devs could at least set it to "the version I'm currently using" so we know it's guaranteed to build on that.

It’s not that easy; the real world has a lot of complexity. That said, we finally did accept a design for this in October; it’s not clear when it’s going to land though.

Because of dependencies, you mean? Even an indication of "this builds fine for me at version X" would be good.

Tons of stuff. Various aspects of dependencies, for example, should this affect resolution? Is this a semver range? A minimum version? Is whatever we choose reasonably forward compatible for any extensions we might pick in the future? Can you write `cfg` attributes based on versions? Many of the same questions apply there. Etc etc etc.

It took about a year to get stuff figured out.

I also suspect that if the plan is to add this as an attribute that developers put in Cargo.toml then there will be a lot of packages that will have the value set to a higher version than need be.

Speaking for myself, I don't know in which exact version of Rust the features that I use was first introduced, and I don't think anyone else knows that either if they use a lot of different Rust language features.

So if I were to add a minimum required version to Cargo.toml for the crates that I put out, I would for sure end up putting the current stable version that I am using myself.

In practice I think that is probably fine, but also a bit unfortunate in a way, that anyone using an older version of Rust, such as those using distro packaged Rust will see Cargo tell them they can't build and run my crate, because I set minimum version to say 1.40.0, and they are using 1.37.0, but actually I might happen to not be using any features beyond what was available in 1.35.0 or whatever in some random crate of mine, but I don't know that and I don't wish to test every change I make to my crates in a bunch of older versions of Rust also because that would slow me down considerably.

On the other hand, if the Rust Team had the resources for it, could the crates.io service be made to detect minimum version of Rust needed based on the features used? Probably a lot of work I would guess. Doubly so when considering different feature flags and other cfg switches.

Again, I don't know the plans you have for how to do it so maybe you are already planning to do it that way but, you guys sometimes run builds on basically all of the crates on crates.io, don't you? Would it be feasible that the crates.io service runs a background service that builds each crate with a few different versions of Rust and records the build results and possibly test results into the meta data for the crates on crates.io? I think that would probably require a lot of server time, and therefore likely cost too much to be possible but it would have been really cool if it was doable.

I’m imagining that’s too much resources, yeah. It’s the same issue with anything that’s created by people; I’m sure that it’ll be fine over time. If and when we do LTS releases that’ll make it easier too...

There's no such thing as a "too current a version of rust". All Rust compilers (since 1.0) compile all previous versions of code and will continue to do so.

In the rare case you might hit something that was removed/modified because of a security exploit, but those are very very rare.

This is not true in practice. Old code has failed to compile for various reasons; off the top of my head, new additions to the prelude, and denied lints that became more restrictive. It's not super rare.

Just a nitpick: Rust 1.40 seems to be the stable version for a couple of weeks now.

First, it’s really cool that their using trust-dns! Second, they probably want to upgrade to the 0.18 release. It’s interesting that the cargo.lock file didn’t restrict the package versions for this case.

Anyway, this tool should probably upgrade to the current 0.18 release now that it’s out, if possible.