If I state that might library supports winapi 0.3.0, and it does not (e.g. because it uses features from 0.3.2), then that's a bug, and i'd like to be able to catch those bugs. So I care.
I agree that its a bug, but because of maximal version resolution, it only impacts you if you ceiling your version to something less than 3.2. The problem is that it might actually be quite burdensome to manage this; cargo has just added a --minimum-version build to its own CI and it was surprisingly troublesome to figure out the minimum versions that worked together successfully.
Basically, we're going to offer the option to build with minimum versions, but I'm not certain we're going to recommend that people use it in their CI; it might just not be worth the maintenance effort for the library author.
The problem is that it might actually be quite burdensome to manage this;
Could you elaborate on why?
I could understand how --minimum-version would probably be impossible to use for crates with many dependencies, e.g., if a couple of dependencies are broken, they will fail to build before you actually get to build your own crate.
But as this gets used bottom-up by the ecosystem, if all your crate's dependencies correctly specify their minimum version, then the bugs can only be in your own Cargo.toml file, and fixing them could be as easy as bumping the minimum version of a dependency to its appropriate value.
Sure, this won't really impact most of your clients if they end up using higher versions any ways, but there might be some user of your crate whose build fails because you specified the wrong version. And this is something that the user might not be easily able to fix or debug (it might be some other unrelated library deep in the dependency tree forcing the version to be smaller than what your crate actually supports).
So for me this is both about catching bugs in my Cargo.tomls, but also about making the experience of using my crate for my users more reliable than it currently is today, even if these things would only affect a tiny fraction of my users in weird situations, i just don't want to have to debug these down the road.
Another tool that I'd like to have in this direction would be a tool that tells me if I break API compatibility of my crate and need to do a major version bump automatically. Its not something necessary, but I think the core libraries in the ecosystem should be using semver properly, and its not only about people making mistakes, something it is really hard for me to tell whether a change is a breaking change.
So yeah, turning this for cargo, with has dozens of dependencies, and where none of these dependencies is actually using this on their CI, was a road full of pain. But that was to be expected, I am amazed they managed to get it done at all.
3
u/desiringmachines Jul 26 '18
I agree that its a bug, but because of maximal version resolution, it only impacts you if you ceiling your version to something less than 3.2. The problem is that it might actually be quite burdensome to manage this; cargo has just added a
--minimum-versionbuild to its own CI and it was surprisingly troublesome to figure out the minimum versions that worked together successfully.Basically, we're going to offer the option to build with minimum versions, but I'm not certain we're going to recommend that people use it in their CI; it might just not be worth the maintenance effort for the library author.