Skip to content

Allow windows-sys 0.61 without MSRV bump #282

Closed

Description

@hanna-kruppe

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.

Activity

  1. epage commented on Nov 12, 2025

    @epage
    Collaborator

    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

    minimal-versions:
    name: Minimal versions
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repository
    uses: actions/checkout@v5
    - name: Install stable Rust
    uses: dtolnay/rust-toolchain@stable
    with:
    toolchain: stable
    - name: Install nightly Rust
    uses: dtolnay/rust-toolchain@stable
    with:
    toolchain: nightly
    - name: Downgrade dependencies to minimal versions
    run: cargo +nightly generate-lockfile -Z minimal-versions
    - name: Compile with minimal versions
    run: cargo +stable check --workspace --all-features --locked --keep-going

    the latest version compatible with our MSRV

    test:
    name: Test
    strategy:
    matrix:
    os: ["ubuntu-latest", "windows-latest", "macos-latest"]
    rust: ["stable"]
    continue-on-error: ${{ matrix.rust != 'stable' }}
    runs-on: ${{ matrix.os }}
    env:
    # Reduce amount of data cached
    CARGO_PROFILE_DEV_DEBUG: line-tables-only
    steps:
    - name: Checkout repository
    uses: actions/checkout@v5
    - name: Install Rust
    uses: dtolnay/rust-toolchain@stable
    with:
    toolchain: ${{ matrix.rust }}
    components: rustfmt
    - uses: Swatinem/rust-cache@v2
    - uses: taiki-e/install-action@cargo-hack
    - name: Build
    run: cargo test --workspace --no-run
    - name: Test
    run: cargo hack test --each-feature --workspace

    the latest version (only runs on master and not PRs)

    latest:
    name: "Check latest dependencies"
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repository
    uses: actions/checkout@v5
    - name: Install Rust
    uses: dtolnay/rust-toolchain@stable
    with:
    toolchain: stable
    components: rustfmt
    - uses: Swatinem/rust-cache@v2
    - uses: taiki-e/install-action@cargo-hack
    - name: Update dependencies
    run: cargo update
    - name: Build
    run: cargo test --workspace --no-run
    - name: Test
    run: cargo hack test --each-feature --workspace

  2. epage commented on Nov 12, 2025

    @epage
    Collaborator

    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.

  3. hanna-kruppe commented on Nov 13, 2025

    @hanna-kruppe
    ContributorAuthor

    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.

  4. epage commented on Oct 29, 2026

    @epage
    Collaborator

    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.

  5. xtqqczze commented on Oct 29, 2026

    @xtqqczze

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions