docs: update README to include guidance on using looser semver ranges for dependencies

[wmmc88]

This pull request updates the dependency version specifications in the crates/libs/sys/readme.md and crates/libs/windows/readme.md files to use explicit version ranges instead of caret requirements. This change improves dependency resolution and helps prevent duplicate versions in downstream projects.

Dependency versioning improvements:

• Changed the windows-sys dependency version in crates/libs/sys/readme.md from "0.61" to ">=0.59, <=0.61" and added an explanation about the benefits of using a version range over caret requirements.
• Changed the windows dependency version in crates/libs/windows/readme.md from "0.62" to ">=0.59, <=0.62" and added a similar explanation. [1] [2]

[kennykerr]

I have been mulling over this and I think it just takes up too much prime real-estate on the readme (and thus crates.io) for these crates to focus on a topic that is not specific to these crates and already documented in Cargo book. It is also a lot harder to actually test this in practice with even the provided testing suggestion not covering all of the pitfalls like breaking changes in intermediate versions and other side effects like target-specific breaking changes.

I think it should suffice to update the readme examples to just use a conservative range of known versions and leave the rest for dependents to figure out on their own. Something like this:

https://github.com/microsoft/windows-rs/compare/range-example?expand=1

What do you think?

[riverar]

I appreciate the 'design with versioning in mind' guidance, though I'm curious about the practical impact for greenfield projects that can only start with a single version.

[wmmc88]

I have been mulling over this and I think it just takes up too much prime real-estate on the readme (and thus crates.io) for these crates to focus on a topic that is not specific to these crates and already documented in Cargo book. It is also a lot harder to actually test this in practice with even the provided testing suggestion not covering all of the pitfalls like breaking changes in intermediate versions and other side effects like target-specific breaking changes.

I think it should suffice to update the readme examples to just use a conservative range of known versions and leave the rest for dependents to figure out on their own. Something like this:

https://github.com/microsoft/windows-rs/compare/range-example?expand=1

What do you think?

I wanted to provide some justification/reasoning on why its a range, and why its specifically important for users of these crates. I'm fine with trimming down the lines about testing, or maybe cutting that completely.

I appreciate the 'design with versioning in mind' guidance, though I'm curious about the practical impact for greenfield projects that can only start with a single version.

If you're an application, then it doesn't really matter if you only put a single version since (hopefully) any lib crates you use (that also take dependency on windows-rs) are specifying a range. If you are designing a greenfield library meant to be used by the masses, then it is in your own interest to have this wider range, or else you'll get people opening issues complaining about conflicting versions.

[kennykerr]

Yes, a sentence recommending a version range should suffice. Perhaps linking to https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html for more information.

[kennykerr]

LGTM - thanks!