gix-url does not compile with the version of url it specifies

[kornelski]

Current behavior 😯

gix-url specifies url = "2.1.1" requirement, but uses features from version 2.2.

Expected behavior 🤔

It should build with the versions it specifies in Cargo.toml, i.e. cargo update -Z minimal-versions.

Normally I wouldn't care about minimal-versions that much, but gix is releasing semver-major versions frequently, which other crates are not keeping up with, and I have multiple duplicate copies of gix in my dependency tree that I'm desperately trying to dedupe.

Git behavior

N/A

Steps to reproduce 🕹

No response

[Byron]

Thanks for reporting!

I think there is quite a bit to unpack here. First of all, I think I know how it's possible to get to this point, but I don't know how this kind of breakage can be detected, nor do I know how it can be prevented.

What I'd want to test is if the versions specified in the cargo manifest work, without altering them in any way. Right now there seems to be now way to do that unless one somehow wants to maintain a Cargo.lock file that specifies all of the manifest versions. cargo +nightly update -Z minimal-versions also only works to some extend here, as it somehow determines the minimal version of url is 2.2, and trying to compile it results in failures in other crates (which simply don't seem to compile anymore).

Even though it's easy to change the minimal required version to what seems to be needed, and to possibly even backport to a couple of major versions of gix-url if this would fix your issue, as of now such drift is likely to happen again.

The other problem, of course, is frequent major releases in the light of a forming ecosystem of interconnected crates which then are likely to use different versions of gix, bloating compile times and binary sizes. I thought about this and don't have a solution except for either releasing less frequently, maybe with intermediate 'alpha' releases that people should not use, or to push for stability early while assuring that all APIs are friendly to upgrades and improvements to the extend possible.

The latter would actually be my preference, but for that, the big problem of error handling needs to be solved, as thiserror assures each new error case can lead to what constitutes a breaking change unless non_exhaustive is specified.

To move forward, I'd need more information about the actual error you are seeing, along with the versions of gix-url that seem to be causing this. That way it should be possible to effectively fix and backport it. It would also be good to know which crates in your tree pull in different versions of gix, maybe one can push for an update there as well in the interim.

[Byron]

It seems to get dependency resolution with minimal dependencies, this feature would be needed: rust-lang/cargo#5657. However, it's unlikely this will be relevant for the issue here as it won't be available anytime soon.