KEMBAR78
docs: update README to include guidance on using looser semver ranges for dependencies by wmmc88 · Pull Request #3754 · microsoft/windows-rs · GitHub
Skip to content

Conversation

@wmmc88
Copy link
Contributor

@wmmc88 wmmc88 commented Sep 9, 2025

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
Copy link
Collaborator

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
Copy link
Collaborator

riverar commented Sep 10, 2025

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
Copy link
Contributor Author

wmmc88 commented Sep 10, 2025

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
Copy link
Collaborator

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.

Copy link
Collaborator

@kennykerr kennykerr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - thanks!

@kennykerr kennykerr merged commit 3af8eb9 into microsoft:master Sep 15, 2025
28 checks passed
This was referenced Sep 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants