Unusual package version ranges

[roy-work]

Cargo.toml specifies some overly strict version ranges:

hyperx/Cargo.toml

Lines 23 to 32 in 58d9a6d

	[dependencies]
	base64 = { version=">=0.10.1, <0.14" }
	bytes = { version=">=1.0.0, <1.1.0" }
	http = { version=">=0.2.2, <0.3" }
	httpdate = { version=">=0.3.2, <0.4" }
	httparse = { version=">=1.0, <1.4" }
	language-tags = { version=">=0.2, <0.3" }
	mime = { version=">=0.3.2, <0.4" }
	percent-encoding = { version=">=2.1.0, <2.2" }
	unicase = { version=">=2.6.0, <2.7" }

This results in some really bizarre behaviors for users of hyperx, like packages getting downgraded when hyperx is pulled in. I'd like to pull this package into a crate I'm working on, to move it off an ancient version of hyper, but the odd range here causes an (not as, but still) old version of hyper to get pulled in. Both are under a RUSTSEC vuln, which is why I'd like to move the crate to hyperx.

Just set these equal to, e.g.,

bytes = "1.0.0"

where they span only part of a single semver compatibility range? This lets Cargo do the right thing, and pull in bug/security fixes as it can.

(Note though, that this doesn't apply to base64, b/c there the range is allowing multiple semver-incompatible versions.)

[nox]

@roy-work FYI #33

[dekellum]

The dependency and release strategy used here emphasizes and has been observed to improve MSRV guarantees, as many ≥1 crates will increase MSRV in minor releases. Note that similar dependency incompatibilities have been handled in the past on short (days) notice, and without much user awareness, but I've unfortunately been away from the project for a while this time, and many upstream changes have accumulated.

Some day maybe rust-lang/cargo#9930 will get implemented and these ≥1 dependencies can be further broadened, but in the near term the strategy is not going to be changed.

I've just released hyperx 1.3.1 which allows httparse 1.4 and hyper up to 0.14.11. httparse 1.5 and any future minor releases will become non-conflicting with a subsequent release including #32.