Avoid <= dependency version specifications that may break builds.

[kpreid]

While updating my dependency on wgpu, I noticed that gpu-allocator has <= version requirements:

egui = { version = ">=0.24, <=0.27", optional = true, default-features = false }
# ...
[target.'cfg(windows)'.dependencies.windows]
version = ">=0.53,<=0.58"

These <= version requirements may break builds in the future. In particular, if egui releases a version 0.27.1, or windows releases a version 0.58.1, and another package in the dependency graph requires one of those versions, Cargo will report a fatal error. This is because <=0.58 does not mean “less than or equal to any version in 0.58.*”, it means “less than or equal to 0.58.0” — the third component is implicitly zero — and Cargo will not allow two semver-compatible versions of the same package in the dependency graph.

Avoid constraining the upper bound of a version to be anything less than the next semver incompatible version (e.g. avoid ">=2.0, <2.4") as other packages in the dependency tree may require a newer version, leading to an unresolvable error (see #9029)

— https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-version-requirements

This change avoids this problem by using only < requirements.

[MarijnS95]

This is because <=0.58 does not mean “less than or equal to any version in 0.58.*”, it means “less than or equal to 0.58.0” — the third component is implicitly zero

This is not true - what is your source to back this up? We tested and documented that this is interpreted as <=0.58.* in #143 (comment).

The quote is about explicitly specifying an upper bound within the semver-compatible range like <2.4 that disallows another crate from selecting ^2.4 or similar.

[kpreid]

I’ve just confirmed in a test workspace that it works as you say. I apologize for the incorrect information — I was sure that I had previously seen exactly this type of requirement cause this problem, but in fact Cargo treats <=0.58 like <0.59. There is no bug here.

[MarijnS95]

@kpreid no worries and thanks for confirming. Just to note, I've constantly been contemplating (in different repositories) this confusion over <=0.58 actually meaning <=0.58.99999..., versus specifying <0.59 for a numeric version that wasn't published yet (which may be misread from time to time - and I like the most recently published version to be grep'able).