MSRV policy is changing beginning 2023-07-01

[jhpratt]

tl;dr starting in July, time is adopting a stable minus two MSRV policy

Starting 2023-07-01, the minimum supported Rust version policy for time will change. Currently, it is all Rust compilers from the previous six months are supported. Once the calendar flips to July, this will change to an "N minus two" policy. This means that the current Rust release will be supported, as well as the two before that. For example, the current stable compiler is Rust 1.66. As such the MSRV would be 1.64.

Why the change? As far as I know, older compilers are not used much for development. This is due to Rust's strong commitment to backward compatibility as well as the ease of updating to a new compiler (rustup update is all it takes). Some users may use an older compiler provided by their distro, but this is a use case that is generally not preferred for development in Rust. While features may land on stable, I am currently prohibited by the MSRV policy from using these for a full six months. By reducing this timeframe, end users will be able to benefit from new compiler features approximately three months sooner than they would have been able to under the current policy.

Does this mean that the MSRV will be bumped constantly? In a word, no. The MSRV will only be bumped when it provides a benefit to the end user. If a Rust release does not contain anything with a user-facing benefit, the MSRV will not be bumped. For example, the only feature from Rust 1.62 I plan on using is #[derive(Default)] on enums. Because this has no impact on end users, the MSRV would not be bumped. On the contrary, Rust 1.65 includes GATs. If this is determined to be useful in a public API, the MSRV could be bumped to 1.65 once Rust 1.67 hits stable. Note that the requirement is for there to be any benefit, no matter how small.

---

Edit:

To avoid complete stagnation, the MSRV may still be bumped after six months for internal improvements. This would only apply if there have not been any features resulting in a public API improvement.

[Thomasdezeeuw]

Copying my reply from rust-lang/libs-team#72 (comment).

I think that's a mistake as that means your giving people only 12 weeks of stability, forcing people to quickly move to newer rustc releases, which is not always possible.

Why the change? As far as I know, older compilers are not used much for development.

@jhpratt not all people using compilers are developers. I think you're forgetting about, for example, (Linux) distributions which have their own stability guarantees, which for most is longer than 12 weeks. This means that any Rust application using the time crate can not be included in many Linux distributions.

I really urge you to reconsider this position.

[epage]

Depends on how deep the dependencies are that you cargo add.

And something improving things incrementally for a subset of people does not invalidate the effort, especially as this is something we'd need anyways in a fully rust-version aware world.

[est31]

I have no clue how that works but maybe it would be possible to somehow filter-out crates incompatible with MSRV when feeding the data into the algorithm, IOW pretend the don't exist? Maybe an ugly workaround but doesn't seem super-hard.

That's precisely how the algorithm deals with yanked crates already, it just pretends the yanked releases don't exist. Years ago I made an experimental patch to implement the approach you describe for MSRV aware-ness. The patch reads the MSRV info from a json file you specify in .cargo/config (ideally it should get into the registry). It's not a large patch, it has less than 100 lines.

Ultimately MSRV aware cargo is no solution to (core) crates having extremely narrow MSRV windows though, as security updates won't be available to users. I see it more as a solution for the odd transitive dependency that unfortunately has a narrow MSRV window, not the majority of crates in your DAG.

[matklad]

am I massively oversimplifying here?

As a former t-cargo member, this sounds right to me. I've looked into that during once_cell debate.

The hard part which unlocks this is getting the info into the index. But it's "database migration" hard, not "we need to bikeshed over the public interface" hard, it's a very clearly useful piece of work which we should just do regardless of how the overall situation evolves.

Once info is in the index, I believe the change to actually make it work on the cargo side is going to be a dozen of lines of code:

• parse the field from index here
• filter-out incompatible versions here

Now, plumbing all the error messages, cli flags and such to make this stabizable is going to be a massive pain, as usual, but I think having this info in the index and a quick hack on the Cargo side would be enough to unlock community innovation (eg, someone can build a custom Cargo subcommand to do msrv-aware resolution by depending on Cargo-crate, etc).

[mitsuhiko]

I believe the combination of filtering out MSRV incompatible crates is one part to make this work, the other would be some sense of categorization of crates within the index of what their MSRV support level is. For instance just because a crate supports an old MSRV does not mean it intents on continuing to do so. As @est31 mentioned it's quite pointless to not have longer MSRV support cycles for core crates and if there is no way to express this intent somewhere, it's hard for a user to navigate that ecosystem.

I wish I could for instance declare a longer lasting MSRV support cycle in my own crates and then also specifically pick dependencies that uphold the same support cycles or already avoiding them to begin with.

[jhpratt]

I am open to doing some (nb: not all) work for MSRV-dependent resolution. Let's message on Zulip for further discussion on that front.

[mitsuhiko]

I can only reiterate my objections for such aggressive compiler retirements. It's unnecessarily user hostile and this will eventually backfire on the entire ecosystem if such core crates are not willing to support older compiler versions.

My comment on the libc crate applies here as well: rust-lang/libs-team#72 (comment)

[jhpratt]

Ironically, the brief discussion resulted in raising the MSRV. The discussion was about a specific version and not policy, however.

[est31]

@est31 Building from git source is an issue that can be solved with the use of Cargo.lock, no?

@jhpratt lockfiles help, especially when you have generated the lockfile at a point in time when the MSRV was the latest version. There is no "time machine" however, nor is there a cargo mode to ignore MSRV non-compliant versions of crates. Even if such a mode existed (and it was rejected during the MSRV field RFC), sometimes crates increase their patch minimum requirements even if they don't need newer functions... it's not perfect. Also, people miss out on bug and security fixes. The easiest is for crates to keep an old MSRV.

[Kixunil]

Asking a user to provide --locked isn't that much of an ask, to be honest.

Yeah, it's not. It's a bit annoying to have to respond "sorry, I forgot to mention --locked in the doc" to confused non-programmers or inexperienced users but not too bad.

the exact situation is true for the compiler and standard library.

In practice people using them backport the fixes. This is at least true for Debian. Bakporting a fix for a library somewhere in the middle of the dep tree is not pleasant, unless the maintainers cooperate in which case it's quite fine.

A new branch whenever MSRV is bumped could work, but then the situation is significantly changed. People would then have to use a git dependency in Cargo.toml rather than using it from crates.io.

Sorry, I meant to say also release on crates.io as a new patch version. That's why it is useful to release minor version with MSRV bump - to prepare for possible future patch versions. It doesn't make sense from SemVer perspective but at least it doesn't break anything.

sometimes crates increase their patch minimum requirements even if they don't need newer functions

Yeah, this is super-annoying, also bumping MSRV for cosmetics like the matches! macro.

[epage]

--locked is not the default (which could be considered a security hole)

Note that cargo will now suggested --locked if cargo install fails, see rust-lang/cargo#10891

[Kixunil]

@epage nice, that helps. It doesn't address the security issue but that's a different discussion.

[AlexTMjugador]

As the maintainer of a library that depends on time, I'm finding the recent MSRV bumps a bit too much:

• MSRV was bumped to 1.62 on 0.3.18 (that's understandable).
• The MSRV was bumped to 1.63 again on 0.3.20 (just barely a week later).

It was stated that "the MSRV will only be bumped when it provides a benefit to the end user", but the changelog for 0.3.20 doesn't provide any benefits to me over 0.3.19. Upgrading to 0.3.20 is, from my point of view, a chore that requires updating my own CI workflows, MSRV and even documentation(!) for no good reason other than "1.63 is an old rustc version".

Quite frankly, such MSRV bumps are likely to cause downstream projects to pin the time version they depend on, which will prevent them from getting potential security updates. That is a great harm to the ecosystem compared to some minor ergonomic improvement.

Please, can this MSRV policy be reconsidered to be a bit more slow-paced? I think it's great as-is for end applications, but it's quite unsatisfactory for libraries that want to be useful for other libraries without asking too much to anyone.

Edit: moreover, I think that there is nothing that should suggest "stagnation" in keeping MSRV constant for more than 6 months if no change from newer Rust versions is needed for internal code. It's not time's role to policy how people upgrade Rust, and if the declared MSRV is actually tested to still work in CI workflows (which it should), it is in fact a good thing that a crate is so backwards-compatible. Of course, it's reasonable to bump it over time even if it provides only internal benefits, but I wouldn't rush it.

[jhpratt]

"never” is way to strong here (I perceive the gap between “never” and “almost never” to be huge though).

That's fair. However, the overlap between situations where it is somewhat reasonable and crates that are intended to be dependencies of others seems extremely small.

I don’t really know a specific cut-off point here, as there’s little visibility into what people actually need.

As I've said elsewhere in this discussion, this is a key point. There's little evidence that people need a low MSRV, and this change is in part an experiment. Worst case is I pause bumps while the policy falls back from N-2 to N-3 and possibly N-4.

[matklad]

That's fair. However, the overlap between situations where it is somewhat reasonable and crates that are intended to be dependencies of others seems extremely small.

There can be lateral dependencies: your project depends on a crate that needs rust-1.52-nightly, and also on hottest-web-framework.0.92.0-beta.8. It might be the case that you want to update the web-framework, to address a critical bug, or to get rid of the biggest chunk of your technical debt, but upgrading the framework forces you onto a new version of a transitive dependency, which in turn forces you to upgrade Rust to a version currently-incompatible with the nightly part of the codebase.

I guess I view these things through knightian uncertainty lens: in the medium-conservative MSRV range, I don’t know and can’t know the distributions of Rust versions people use without ability to upgrade them. Rather than trying to second-guess the most cost/benefit efficient MSRV, I look only at the cost curve (where I have full info, cause that’s on my side), and pick a “diminishing returns” point. This position might very-well be wrong! I wouldn’t be surprised even if something as aggressive as “only supports latest stable” is ecosystem-optimal!

[jhpratt]

For sure, that is a possibility, and I believe you when you say you've encountered it before. With that said, I don't personally believe the downsides of that outweigh the benefits of pushing improvements to 99% of users sooner (guessing at the number). It's worth remembering that the MSRV will only be bumped to a maximum of N-2 when there's a benefit to the user, whether that's making a function const, API improvements, etc. Anything that's strictly internal (or is only incidentally public) remains stable minus six months.

There is unquestionably an uncertainty here. No one knows what the best/optimal policy is. If there is a better way of finding out than by doing it the hard way, by all means let me know! Unfortunately I don't believe there is, and we're both very familiar with the Rust ecosystem.

[fintelia]

The lateral dependencies point also becomes increasingly relevant as your dependency tree gets larger. I maintain a crate with 170 transitive dependencies^* (just under half included with the default features). We take the position that users can't be expected to manually select versions for all those, so if automated tooling doesn't give you a working build for a given Rust version, then de facto that Rust version isn't supported.

Unfortunately that isn't always easy. Just with the latest Rust we had one dependency that compiled fine with stable-1.69 but was broken in 1.70 and now a different transitive dependency that apparently has a N-0 MSRV policy bumped to requiring 1.70 just a few days ago.

To be clear, technically, no one broke semver in either case. The mp4parse crate was fixed by adding type annotations (after a short scramble to get in contact with the maintainers to publish a new release). And the other was a MSRV bump which is widely regarded as not semver breaking. But it still feels like something is broken. In fact, I actually found this thread from trying to track down whether there's a more sustainable approach. (I should really write up a blog post going into more detail, but that'll have to wait for another day...)

_{^*You might ask if this many dependencies are really needed, but the image crate has the almost quixotic goal of being able to encode and decode all major image formats. A big part of that is pulling in format-specific crates to deal with all but the simplest image formats. Multiply around ten format-specific crates each with a dozen or two dependencies and the number starts growing pretty fast.}

[jhpratt]

We take the position that users can't be expected to manually select versions for all those, so if automated tooling doesn't give you a working build for a given Rust version, then de facto that Rust version isn't supported.

This is a cargo problem, as it doesn't have MSRV-dependent resolution. As I've indicated elsewhere, I'm willing to put in some of the work to make this happen, as it's something I'd like to see as well.

[Dekkonot]

I maintain a crate that does not depend upon time directly. While we don't generally have a MSRV policy beyond 'it works on the latest release', we would like to confirm that building the crate works on older versions unless we direly need a new feature. A few days ago, the CI check for our established MSRV broke because of time releasing a new version. A quick check indicates that it was the reason we had to update our MSRV the previous time as well. Again, we do not depend upon time and our dependency versions haven't changed.

The MSRV of time being bumped on patch releases is to blame. While you're well within your right to make whatever breaking changes you want in pre-1.0 crates like time, Cargo doesn't treat their versioning any differently than post-1.0 crates, so patches aren't treated significantly. This is generally a good thing but it means that our dependencies (I don't know which one yet) are causing us to pull in a breaking change without us having any say in the matter. We could be using --locked for CI but that would just hide the issue for our downstream consumers to discover because we're a library and not a binary.

I do not want our MSRV policy to be set by yours because a crate we depend on doesn't do a good job at locking their pre-1.0 dependencies. We don't need to support older Rust versions but we want to and it is frustrating that we can't. While there's a few solutions to this, I would prefer to simply go through you before trying any of them.

[fintelia]

Unless you control all dependencies yourself or all your dependencies have MSRV policies at least as conservative as yours. I think this is part of what makes such MSRV policies so controversial: if you adopt framing (2) then your dependencies dictate your own policy. And of course those libraries can only have policies as strict as their dependencies...

[jhpratt]

Yes, but MSRV policy != MSRV. time currently could have an MSRV of 1.66 under current policy, but there's no reason to bump it at the moment, so it remains 1.65.

Ultimately, if/when cargo gains MSRV-dependent resolution, (2) will fundamentally not matter.

[8573]

then your dependencies dictate your own policy

I don't doubt that this happens, but I don't think it's strictly necessary: one's policy also could dictate (a criterion for) one's dependencies, or some combination of the two could apply.

[fintelia]

@8573 Yeah, that's a better phrasing. And it especially explains why a library changing its policy would be such a big deal. People who accepted it as a dependency based on the old policy have to re-evaluate whether to keep using it. Which raises a question I hadn't thought about before: should changing your msrv policy perhaps be a semver breaking change?

[jhpratt]

That's precisely why I gave more than six months notice of the policy change. I also previously publicized the decision.