minrust is brittle from a project maintenance perspective

[epage]

If I don't check in my lock file, then the CI will get all of the latest dependencies which might bump their minrust at any moment.

If I do check in my lock file, it is at least on my end (when I run cargo-update) that I have to deal with it.

[epage]

One option is that when running minrust jobs, we pass -Z minimal-versions (an unstable flag).

The upside is we are also verifying our manifest file has the correct dependencies listed.

The downside is that this assumes all our indirect dependencies also verify their manifest files.

[jonhoo]

Hmm, yeah, that's a good point. I'm not actually sure what the best way to fix this is. minimal-versions would be great, but as you point out, that's quite brittle too. I don't have a good answer. I'd lean towards keeping the current solution, and maybe introducing another optional minimal-versions stage.

[epage]

True, verifying minimal versions is a potentially useful feature on its own, so I created #25.

[BurntSushi]

The downside is that this assumes all our indirect dependencies also verify their manifest files.

Indeed. I'd love to be able to run the minimal-version check, but I've found that I can't in practice. Core crates like rand refuse to do it, so it screws the pooch for pretty much everyone else.

If I don't check in my lock file, then the CI will get all of the latest dependencies which might bump their minrust at any moment.

I typically like this, because this does occasionally result in a bug request filed against the dependency that bumped the MSRV. But it is more maintenance. And of course, this only applies to libraries. (If I had any libraries with a dozens of dependencies, then I'd probably give up on maintaining an MSRV at all, since it's unlikely that all of my dependencies will care about it.)

[epage]

Drat, I was hoping there was something I had missed in the MSRV conversations to make this all easier :(

I typically like this, because this does occasionally result in a bug request filed against the dependency that bumped the MSRV

I feel I'm missing something here. From my understanding

• bumping MSRV is not a breaking change, so my version constraint can't dictate MSRV
• There is no aligned timetable for bumping MSRV
• There is no alignment on what MSRV should be

So from this, I'm unsure what bug report I could file to my dependencies that would be meaningful.

And of course, this only applies to libraries. (If I had any libraries with a dozens of dependencies, then I'd probably give up on maintaining an MSRV at all, since it's unlikely that all of my dependencies will care about it.)

:( too many libraries with too many dependencies. Plus my CI could break at any time and I really dislike that, especially for the negative impression it might give new contributors.

[BurntSushi]

So from this, I'm unsure what bug report I could file to my dependencies that would be meaningful.

Perfectly reasonable, but not everyone is aware of the MSRV issue. Lots of folks build and maintain libraries without ever having worried about it. Some of them, when pointed out the MSRV concerns, will happily oblige and fix their code to compile on older versions. Because of Rust's aggressive deprecation policy, the vast majority of MSRV bumps are uninteresting or just fixing deprecation warnings. If you come to folks with a concern, some will be receptive to it.

Bumping the MSRV is also sometimes a signal of something else going wrong. This happened in one of my transitive dependencies, and it was because they added two fairly heavyweight dependencies to what used to be a crate with no dependencies. I looked into, filed a bug, and it turned out that neither were actually needed.

As I said, this does add more maintenance burden. And if my library had a lot of dependencies, I wouldn't bother with this at all.

I really dislike that, especially for the negative impression it might give new contributors.

Meh, shit happens. Sometimes a nightly release will break everyone's build. With that said, if this is actually happening to you a lot, then yeah, I just wouldn't bother with MSRV at all, because it probably means your library has a lot of dependencies. I only do it because it's a somewhat rare occurrence. For example, I don't think I remember the last time it happened to me. (But that's likely only because I don't always run tests with the MSRV, since my dev-dependencies tend to include rand, and the rand folks bump the MSRV a lot.)