You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several anstream crates currently require windows-sys 0.60.2 and don't allow 0.61 or newer. The 0.60 -> 0.61 bump is different from other bumps because 0.61 is the first version that uses the raw-dylib feature to have rustc generate the import library, instead of pulling in large pre-compiled import libraries via windows-targets. Usually people care more about avoiding multiple windows-sys versions and are happy to stay on older versions to achieve this, but now there's tangible advantages to preferring the newer version (avoiding pre-built blobs, smaller download size and vendor directory).
Bumping the windows-sys requirement from ^0.60.2 to ^0.61 would break MSRV (as discussed in #276). If this was just a matter of waiting N months until MSRV becomes 1.71 automatically, I'd just wait. But since there's no clear timeline, I don't want to wait indefinitely. For dependencies that are replaced by new std features, this is addressed by "polyfill" crates, but that doesn't seem applicable here.
Allowing both windows-sys 0.60 and 0.61 would resolve this without having to bump MSRV. Several other libraries with MSRV < 1.71 already do this (rustix, errno, tempfile, nu-ansi-term, is-terminal, os_pipe, jiff, ...). Allowing both 0.52 and 0.59 was previously rejected in #238 and I understand the reasons @epage gave. However, I think the trade-off is significantly different for 0.60 and 0.61:
Due to MSRV, "just" updating to 0.61 and not supporting older versions is not an option for the foreseeable future (I'd be happy to be proven wrong about this)
Staying on 0.60 only imposes a tangible cost on dependents with higher MSRV
The only change in 0.61 is the switch to windows-link. That's only a breaking change for esoteric reasons which don't affect anstream. As long as there's nothing taking function pointers of windows-sys functions and expecting them to have a specific ABI string, there's no need to delicately avoid stepping on API differences between the two versions.
Our windows code at this point is relatively low touch.
We will have compilation or even test coverage for 3 versions (see below). We likely don't need coverage for everything between those.
The main thing lacking in that coverage is there isn't a guarantee we are cover the full range of the version requirement. We also don't test the latest version for PRs.
RenovateBot will just keep updating the upper bound and will be easy to overlook it, so this isn't as much about this version but about doing this for all future breaking changes going forward.
I was hoping we could recommend a windows-only job that ran cargo update windows but we still have a couple versions in our dependency tree because we depend on an old version of clap.
Oh well.
Let's go ahead and move forward with the dependency version requirement change for now. We can always adjust as needed.
I suspect that the CI coverage won't work out that favorably: the minimal-versions job and the "run cargo update first" job only run on Ubuntu right now, and the MSRV-aware resolver doesn't explore multi-major-version ranges. But I'll create a PR and then we'll see what PR CI actually ends up doing and think about possible improvements.
We can narrow the range if we just bump the MSRV but then we'll just run into this again on the next MSRV bump of windows-sys (not seeing any policy for when they bump).
I think the decision should be to be narrow or wide independent of the MSRV. The question is are the build times worth the cost of those Cargo bugs.
Activity
epage commentedon Nov 12, 2025
Stepping through some thoughts.
Our windows code at this point is relatively low touch.
We will have compilation or even test coverage for 3 versions (see below). We likely don't need coverage for everything between those.
The main thing lacking in that coverage is there isn't a guarantee we are cover the full range of the version requirement. We also don't test the latest version for PRs.
RenovateBot will just keep updating the upper bound and will be easy to overlook it, so this isn't as much about this version but about doing this for all future breaking changes going forward.
the oldest version possible
anstyle/.github/workflows/ci.yml
Lines 75 to 92 in 1d13dd2
the latest version compatible with our MSRV
anstyle/.github/workflows/ci.yml
Lines 33 to 57 in 1d13dd2
the latest version (only runs on master and not PRs)
anstyle/.github/workflows/rust-next.yml
Lines 48 to 66 in 1d13dd2
epage commentedon Nov 12, 2025
I was hoping we could recommend a windows-only job that ran
cargo update windowsbut we still have a couple versions in our dependency tree because we depend on an old version of clap.Oh well.
Let's go ahead and move forward with the dependency version requirement change for now. We can always adjust as needed.
hanna-kruppe commentedon Nov 13, 2025
I suspect that the CI coverage won't work out that favorably: the minimal-versions job and the "run
cargo updatefirst" job only run on Ubuntu right now, and the MSRV-aware resolver doesn't explore multi-major-version ranges. But I'll create a PR and then we'll see what PR CI actually ends up doing and think about possible improvements.epage commentedon Oct 29, 2026
In #317, @joshtriplett is proposing we go back on this because of problems within Cargo related to multi-major version ranges
rust-lang/cargo#9029
rust-lang/cargo#5529
https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Cargo.2Elock.20non-deterministically.20flipflopping/with/520024108
We can narrow the range if we just bump the MSRV but then we'll just run into this again on the next MSRV bump of windows-sys (not seeing any policy for when they bump).
I think the decision should be to be narrow or wide independent of the MSRV. The question is are the build times worth the cost of those Cargo bugs.
xtqqczze commentedon Oct 29, 2026
There’s a PR in development that should resolve rust-lang/cargo#5529; it just needs a reviewer. It might be worth holding off on this for now.