v0.7.34 requires Rust 1.89

[kixelated]

I saw the semvar bump to v1, grats.

However, I think v0.7.34 accidentally requires 1.89:

wide/Cargo.toml

Line 15 in 9ff04e9

rust-version = "1.89"

[Lokathor]

Apparently the v1.0 was premature, and I had to yank it 10 minutes later unfortunately.

However, separate from that: I don't understand the nature of this issue. Like, what is the problem?

[kixelated]

Apparently the v1.0 was premature, and I had to yank it 10 minutes later unfortunately.

However, separate from that: I don't understand the nature of this issue. Like, what is the problem?

My fault for not elaborating. I was running cargo update to automatically pull in the latest dependencies, but my CI setup is still using 1.88. Such a huge MSRV jump should also be a semvar bump, either 0.8.0 or 1.0.0, especially because 1.89 was only released this month.

I've downgraded for now.

[Lokathor]

I was under the impression that current cargo doesn't select crate versions that aren't able to build on the version of rust being used, so it shouldn't select wide-0.7.34 if you're on rust 1.88

[kixelated]

I was under the impression that current cargo doesn't select crate versions that aren't able to build on the version of rust being used, so it shouldn't select wide-0.7.34 if you're on rust 1.88

Developers can use the latest Rust, bump Cargo.lock, and then it can break on CI if it is using an older version of Rust.

[mineichen]

I use rust:1.87, which doesn't respect the rust-version yet when running cargo update
As a workaround, i just copied the wide entry in Cargo.lock and used it to replace the entry in my new Cargo.lock... This way, all other dependencies were updated... But this caused multiple libraries without a Cargo.lock to suddenly fail in CI...

[Lokathor]

I asked around, and the "fix" is that you need to opt-in to resolver="3" in your crate's Cargo.toml, or have 2024 edition which uses resolver 3, before you do the update. Then the rust-version will be handled as intended.

[Lokathor]

Developers can use the latest Rust, bump Cargo.lock, and then it can break on CI if it is using an older version of Rust.

As more crates move to using resolver 3 this will probably become an increasingly unworkable thing to do. If your CI is older than your local version, you'd have to do cargo +oldversion update so that the update is resolved using the CI version.

[th7nder]

In my opinion, MSRV bump should be also bumping the the minor in the major.minor.patch.
The reason is, most of the deps just specify "wide = 0.7.15", which means "wide = ^0.7.15".

Our library is using wide waaay downstream quinn -> quinn-proto -> fastbloom -> wide and we support Rust 1.86.0 only for certain reasons. We do not commit Cargo.lock to the repo, as this is a library.
So now, the builds are broken as the wide is automatically bumping to the newest version.

My suggested course of action would be to release v0.7.35 without MSRV bump, and then release v0.8.0 with MSRV bump.

[Lokathor]

rust-lang/cargo#14754 stabilized resolver 3 as part of 1.84, so it's available to your project on 1.86.

[kixelated]

@Lokathor the main problem is the transitive nature of this MSRV bump. Because your library now requires Rust 1.89 or resolver=3, my library also now requires it, as do all downstream users of my library. It's a lot to ask every downstream user to fix their environment.

I think the work-around is wide = "=0.7.33" in my Cargo.toml, and hopefully the linter doesn't see it as an unused dependency. But in general it's generally a good idea to bump the minor version on a major MSRV change so it's an explicit opt-in.

Again I just thought it this was a mistake because 1.0.0 was released at the same time and that's a perfect time for a MSRV bump.

[kixelated]

Our library is using wide waaay downstream quinn -> quinn-proto -> fastbloom -> wide and we support Rust 1.86.0 only for certain reasons. We do not commit Cargo.lock to the repo, as this is a library. So now, the builds are broken as the wide is automatically bumping to the newest version.

I mentioned this in the Quinn discord and they're going to cut a release soon. The latest code on main already uses a newer fastbloom version which no longer depends on wide, inadvertently fixing the issue.

[Lokathor]

Overall, it is my sincere prediction that the whole rust ecosystem is going to be moving to msrv bumps in semver compatible versions as the new common practice, and downstream people will just have to actually update their coding practices and use the new resolver.

But for now, I guess it's fine to just yank the version.