Minimum Rust Version

[mitsuhiko]

The latest version of once_cell bumps up the minimum requirement up to 1.56 which is a huge jump. Is it conceivable to do a major version bump for this so that people who want to depend on it for libraries that wan to support older versions can stay on the old version?

[matklad]

The short answer is no: per current policy, MSRV bump is not considered a semver breaking change. I want to avoid every reverse dependency having to change their Cargo.tomls (and their own major version, if they happen to expose once_cell via a public API).

After re-reading rust-lang/libs-team#72 couple of times, the policy I decided for once_cell is:

---

We support workflows which target up-to-date, supported versions of Rust compiler, but we also give somewhat generous grace period, as keeping perfectly up-to-date is hard.

We explicitly do not support workflows which depend on using the old compiler. Making sure that the latest once_cell can be compiled with rustc packaged with debian stable is a non-goal.

If users of once_cell find themselves with an outdated compiler, the following actions are suggested:

1. Find a way to upgrade compiler
2. If using old compiler is required, stick to old version of once_cell as well
3. If a combination of old compiler and new once_cell is required, it's on the consumer to maintain a fork with backports.

---

The following considerations were the most salient for me:

• Rust's own policy is essentially "live at head" -- only the latest rustc is officially supported
• The number of people who are stuck with the old compilers is relatively small

An orthogonal policy is that MSRV bump is not considered semver breaking. There are two justifications for that:

First, this creates ripple effect over ecosystem, where each reverse-dependency has upload a new version with a different Cargo.toml. If the crate also happens to be part of the public API or pushes revdep's own MSRV, the reverse dependency is required to bump its major as well. Practically, not every rev-dep will notice new once-cell, so an extra burden falls on folks maintaining applications with Cargo.locks, who now need to chase their upstreams to avoid duplicate entries in Cargo.lock.

Second, bumping sevmer on MSRV makes the ecosystem less compatible with older compilers. Consider once_cell 1.0.0 with 1.42 as MSRV and kittens 1.0.0 which depends on once_cell = 1 and has it's own MSRV of 1.48. Now, once_cell bumps its MSRV to 1.56. The two scenarios are:

A: once_cell releases 2.0, kittens updates its dep to 2.0 and releases kittens 2.0 with MSRV of 1.56. Then, kittens releases 2.1 with a new API. A binary project rip_toys wants to use this new kittens API, so it upgrades to 2.1. Now, it's impossible to use the latest version of rip_toys on debian stable, because of MSRV.

B: once_cell releases 1.1. kitten does nothing: it still supports 1.48 when Cargo.lock contains once_cell = 1.0.0. When kittens adds a new API, it publishes 1.1.0. rip_toys uses the new API, but it keeps once_cell=1.0.0 in its Cargo.lock. As a result, newest version of rip_toys stays compatible with debian stable.

To rephrase this more mathematically, MSRV means that there exists a combination of dependencies which can be build with that compiler, not that any combination of dependencies can be build with it.

The exists formulation gives more freedom for actual users with Cargo.locks to pick their deps.

---

One practical problem with the above is that, if you naively test MSRV on CI, your CI might now be broken by upstream releasing a new version to crates.io. To solve this problem, the following rule is used:

MSRV CI: if you are not using the latest stable compiler, you must use Cargo.lock.

The suggested way to do this is to commit Cargo.lock.msrv file to the repo, and cp Cargo.lock.msrv Cargo.lock when running CI for MSRV. Here's how once_cell itself dose that:

once_cell/xtask/src/main.rs

Lines 43 to 48 in 97edd07

	{
	let _s = section("TEST_MSRV");
	let _e = push_toolchain(&sh, MSRV)?;
	sh.copy_file("Cargo.lock.msrv", "Cargo.lock")?;
	cmd!(sh, "cargo build").run()?;
	}

---

Finally, there are three specific things anyone feeling strongly can do to improve the situation:

• work on stabilizing Tracking Issue for once_cell rust-lang/rust#74465
• teach cargo to use rust-version during version selection
• write a gum & duct tape script which calls cargo update --precise && cargo check in a loop for creating Cargo.lock for old compilers without direct support for rust-version in Cargo.toml.

[mitsuhiko]

Given that this is where the ecosystem is going, I will likely have to stop maintaining my own libraries for old rust versions.

teach cargo to use rust-version during version selection

I can't even imagine how this works in the resolver given the complexities of this. The resolver would have to back out a huge chunk of the dependency graph if it first encounters an incompatible version of a library.

I think the practical implication of this is that the community starts to restrict to test only against latest Rust again or maybe some quite recent version.

[matklad]

One question I have here: today, once_cell's MSRV is described as "conservative" in readme and 11 months for me does sound conservative, though pretty close to the boundary. I'd like to get a rough "temperature reading" to use the words in a useful way:

Could 11 months old MSRV be called conservative?

• 🚀 : if yes
• 👀 if no