Keep your #Cargo dependencies up to date automatically with dependeabot:
@kornel It's not about my project. It's about our dependencies suddenly bumping their dependencies in a breaking way and us having to mess with pinning versions etc.
@stevenroose It looks like you're trying to use an old unsupported version of the Rust compiler? Sorry, but within the community there's no consensus whether min supported Rust version falls under semver rules.
@kornel That's interesting, I'll take a look at that, thanks!
The problem is that updating your compiler is not an easy process if you don't want to just blindly download a binary from a website/distribution.
We usually kept up with the latest rustc version that could be built with gcc, which is 1.29. From then on you could boostrap further versions by compiling them one at the time, but it becomes a time-consuming process.
@stevenroose I know bootstrapping is a major PITA. But I wonder why don't people go through this pain once, and then share hashes of bootstrapped executables?
@stevenroose Presumably if someone proves trusting-trust once, and you trust them, you don't need to go through all this hassle yourself, and just download latest reproducible version of the compiler.
@kornel Hmm, idk if rustc is deterministically buildable. But yeah that would make sense. With guix though companies could have their own internal build cache so that they would also only have to do the build once. NixOS allows something similar, but most Nix packages are not bootstrapped, just downloaded.
@kornel Also, hash-based-addressing would be a good step in the direction of supporting this. F.e. repositories built on IPFS.
That would also reduce the danger of an attack where crates.io is hacked or something. We already use vendoring, but many projects don't.
@stevenroose rustc should be reproducible. Some releases have regressions, but generally it's 99% there.
@kornel Hmm, while a very nice attempt, the drawback "This means that the registry won't contain any newer crates, even if they'd be compatible." is quite bad. There's many projects, like many of the dependencies that we maintain ourselves, that do make updates but respect MSRV.
But I might go and try see how that would work on our current project!
@stevenroose There's a bit of it which I haven't released, because I never got it to the point of running on not-my-machine. But internally I've implemented this as a blocklist of semver ranges, and a tool that goes through registry and removes blocked version ranges.
@stevenroose so if foo 1.2.3 broke msrv, then you add foo >= 1.2.3 to blocklist, regenerate registry, and Cargo will never see these again.
@kornel Oh we use various version of the compiler. I didn't know there was such a thing as an "unsupported version" of cargo? Unless you mean mrustc or so?
We usually use 1.36 and yesterday I also had a project failing to build because `subtle` included some new Rust features without bumping semver.
IMHO the semver definition of "breaking" is quite clear. If it's something that could be built previously and now cannot anymore.
@stevenroose I mean officially, all Rust versions older than 6 weeks are abandonware. The project only moves forward, and won't release patches for previous versions even if there were serious problems. Update to latest-latest is always the only answer.
@stevenroose In Rust ecosystem semver is usually interpreted as "doesn't break with the latest stable". Some support some vaguely older version enough for Debian. But 1.29 is far behind, before 2018 edition, before async.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!