Update windows dependency to 0.62

[nicopap]

Why

In my project, I've other dependencies that depend on 0.62, thread-priority depends on 0.61, this results in duplicate windows deps, which increases the size of my binary, and my compilation time.

Testing

I tested the change on my Windows machine running cargo test, all tests pass.

Breaking

Depending on whether this crate re-exports or exposes types from windows, this may be a breaking change.

---

Cheers :)

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

• Cargo.toml is excluded by !**/*.toml

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: d0616f67-9223-4740-9e93-bb26de940e7b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[iddm]

I think it is better to depend on it via >0.61, so that the unification may happen in case any other version is used too.

Thank you for the help!

[iddm]

Pardon, just realised it should have been inclusive: >=0.61 :-)

[nicopap]

Hoy, I just tested it with the project in question, and it removes the duplicate dependencies (the >=0.61 version)

Thank you for your time and the work you put into this crate!

[iddm]

Hoy, I just tested it with the project in question, and it removes the duplicate dependencies (the >=0.61 version)

Thank you for your time and the work you put into this crate!

Great to hear! Thank you for the contribution!

[iddm]

I've just published 3.1.0, enjoy your day!

[nazar-pc]

It is somewhat dangerous to do this. Cargo will pick the latest available compatible version, so it is possible that hypothetical 0.123 will introduce breaking changes and this crate will stop compiling completely.

I'd recommend to have both upper and lower bounds on the version that are known to all work. This is what many crates seem to be doing with windows dependency specifically since there are way too many versions of it and they are all so large.

[iddm]

It is somewhat dangerous to do this. Cargo will pick the latest available compatible version, so it is possible that hypothetical 0.123 will introduce breaking changes and this crate will stop compiling completely.

I'd recommend to have both upper and lower bounds on the version that are known to all work. This is what many crates seem to be doing with windows dependency specifically since there are way too many versions of it and they are all so large.

I will never recheck the versions with which it works and doesn't. I would expect a feedback with someone saying it breaks, or CI failing in the future. Maybe it is a good idea to add there a nightly job that also updates the dependencies.

I have shot myself in the foot many more times when a crate I wanted to use either couldn't work with the dependency I wanted (usually newer), or pulling in the one that polluted the whole dependency tree.

[nazar-pc]

Well, this PR is the example of shooting in the foot: it will likely break at some point in the future. This is IMO significantly worse than pulling an extra dependency.

If someone needs a newer version of windows crate that is known to be compatible, they can submit a PR and a one-line change can be shipped in a patch release without affecting anyone negatively.

As is, this is a ticking bomb waiting to break downstream projects. simple cargo update can pull a newer version of windows crate and break things in a very confusing way and the only reliable way to fix that would be to edit the lock file manually.

[iddm]

Well, this PR is the example of shooting in the foot: it will likely break at some point in the future. This is IMO significantly worse than pulling an extra dependency.

If someone needs a newer version of windows crate that is known to be compatible, they can submit a PR and a one-line change can be shipped in a patch release without affecting anyone negatively.

As is, this is a ticking bomb waiting to break downstream projects. simple cargo update can pull a newer version of windows crate and break things in a very confusing way and the only reliable way to fix that would be to edit the lock file manually.

https://github.com/iddm/thread-priority/actions/runs/27461889160

Lower bounds (>=) are good because they're provable - we compile against the floor - but set them to the true minimum the code needs, or we cause duplication the other way. Speculative upper bounds (<) are bad: one can't prove a not-yet-released version breaks the crate depending on it, and on a huge crate like windows an over-tight cap forces duplicate copies. The "no upper bound" is also unprovable, though; this is why I created a nightly job whose goal is to catch a breaking release within a day, so it becomes possible to add a proven cap in a patch. This crate uses a tiny subset of the interface of the windows crate that is highly unlikely to be breaking every single release of theirs. So, given the low probability of it happening and the nightly monitoring, the issue is simply not as bad.

[nazar-pc]

we compile against the floor

No, you're not because this repo doesn't have a lock file. This PR specifies >=0.61, so Cargo picks whatever newest version satisfies that requirement, which happens to be 0.62.2 in that CI run. Some 0.123 or 42.42 in the future will satisfy that requirement too, but will quite likely have a different API, set of available features or both, making downstream projects fail to compile without manual lock file editing.

The "no upper bound" is also unprovable, though; this is why I created a nightly job whose goal is to catch a breaking release within a day, so it becomes possible to add a proven cap in a patch

And that is precisely the problem. By the time you detect it, downstream users are already suffering and will not stop suffering unless they upgrade this crate too. The correct way to approach this is to have both lower and upper bound, ensuring everything within range is guaranteed to compile, here is an example from a popular crate:

[target.'cfg(windows)'.dependencies.windows]
version = ">=0.53, <=0.62"
features = [
    "Win32_Graphics_Direct3D12",
    "Win32_Graphics_Dxgi_Common",
]
optional = true

https://github.com/Traverse-Research/gpu-allocator/blob/46539528a94f6afb7ce77089fb95156aa0e9a082/Cargo.toml#L52-L58

In case of this PR, it should have been >= 0.61, <0.63 because there is no guarantee about what 0.63 will look like yet. Once it is out, a new version of this crate can change that to >= 0.61, <0.64. This way things are predictable for everyone at the cost of possible dependency duplication (thankfully Microsoft seems to not ship new windows crate versions as often lately and use patch versions too).

If you don't have an upper bound, you're just waiting for trouble to happen. It may or may not happen, but it is still a bad practice to have open-ended version bounds.