Extend `windows` dependency range to `0.53-0.62`

[MarijnS95]

• https://github.com/Microsoft/windows-rs/releases/69 (and following patch releases 70 and 71)

[oblique]

Any reason on why you want a range instead of just 0.61?

[MarijnS95]

@oblique the windows crates are becoming more and more prevalent in the entire Rust ecosystem, while at the same time releasing breaking versions on a regular basis. This in turn results in a lot of downstream updating churn, especially now that most of the bindings and core foundations have settled in and barely see many breaking changes.

While mostly important for crates that have windows types in their public API, this also applies to crates that only use windows internally: we still prefer to cut down on the otherwise many duplicates that we have.

This way you can publish a patch release and anyone using any version of windows in range 0.53 - 0.61 will be unaffected by this bump an is free to pick whichever version suits their project. Once they're ready to upgrade, this crate no longer needs any changes to go with it.

[oblique]

Cargo allow using of multiple semver-incompatible crates at the same time. So a user that uses 0.53 can still use a crate with 0.61. Try this:

[dependencies]
named-lock = "0.4.1" # uses windows 0.53
windows = { version = "0.61.1", features = ["Win32_Foundation"] }

I prefer to update it to 0.61 instead of a range.

[MarijnS95]

@oblique how does that address this comment above:

we still prefer to cut down on the otherwise many duplicates that we have.

To word it differently, we do not want multiple versions of windows in our dependency tree. Even if cargo supports it.

With this range we can use 0.61 while someone else may be trailing behind on another version without missing out on other changes and bumps in your crate.

There are obviously many alternatives:

• Use windows-sys for the mostly (it seems) non-high-level need of bindings. This is a lighter crate but still suffers from the same release cadence. And missing HSTRING helper for CreateMutexW();
• Generate lower-or-higher-level bindings using windows-binden. This still puts a dependency on windows-core/windows-strings/windows-result unless all its code is generated into this crate which shouldn't be too much. EDIT: Tried this in #14 now that --specific-deps exists on windows-bindgen, but it's not fully getting rid of the windows-core dependency yet: https://github.com/microsoft/windows-rs/issues/3792

---

Of course a version range normally requires "rigorously" testing all compatible versions to make sure it is actually valid for every breaking release, but crates should at the very least be testing with cargo +nightly -Zminimal-versions generate-lockfile to ensure their minimal (also non-range, just regular default caret matching semver compatible crate selection is correct).