Closed wllenyj closed 2 years ago
This proposal sounds sane to me. We can enable dependabot updates for rust-vmm crates as well so that we can merge the dependency updates easier.
CC: @rbradford @sboeuf @bonzini @jiangliu what do you think?
Looks good to me:)
Sounds good to me
I agree that switching to = x.y.z
is a good idea, but that would only start fixing our problems once crates start switching from zero versions (0.y.z) to stable versions (1.y.z), as otherwise each increase of y
would mean an incompatible version. I think vm-memory
and vmm-sys-util
are good candidates for becoming stable.
I've started packaging rust-vmm components in Fedora, and dealing with 0.y.z
versions is making it really painful.
but that would only start fixing our problems once crates start switching from zero versions (0.y.z) to stable versions (1.y.z)
Mentioned in semver-compatibility:
Versions are considered compatible if their left-most non-zero major/minor/patch component is the same.
For example, 1.0.3 and 1.1.0 are considered compatible, and thus it should be safe to update from
the older release to the newer one. However, an update from 1.1.0 to 2.0.0 would not be allowed to
be made automatically. This convention also applies to versions with leading zeros. For example,
0.1.0 and 0.1.2 are compatible, but 0.1.0 and 0.2.0 are not. Similarly, 0.0.1 and 0.0.2 are not compatible.
So we can increase y
in the 0.y.z
for incompatible version, otherwise increase z
for bugfix version.
and also increase x
in the x.y.z
for incompatible version, otherwise increase y
or z
for bugfix version.
So we can increase
y
in the0.y.z
for incompatible version, otherwise increasez
for bugfix version. and also increasex
in thex.y.z
for incompatible version, otherwise increasey
orz
for bugfix version.
This is our current strategy. This is why your proposal for using caret dependencies works even for crates that are not at a major version. I think we can separate the discussions:
=0.x.y
, but ^0.x.y
which means that crates update automatically to newer patch versions, but don't update to minor versions which might have compatibility issues.This is not fixed for vm-memory, re-opening the issue.
The crates in rust-vmm use
>=
comparison-requirements to specify specific dependencies. This places a significant maintenance burden on the user who uses it.Problem
We use
vm-memory
as an example because the structure ofvm-memory
runs through the vmm ecosystem and cannot use two different versions. See version-incompatibility-hazards for reasons.my-lib 0.1.0
, it depends onlinux-loader
andvm-memory
, andlinux-loader
depends onvm-memory >= 0.6
. The version ofmy-lib
that depends onvm-memory
requires:0.8.0
, not older versions.vm-memory 0.9.0
is released, it will be a disaster. Since cargo's strategy is to use the greatest version. Then, all libraries that depend onvm-memory >=
must be fixed and released a new version. And the previousmy-lib 0.1.0
will not work. This break is silent.cargo update -p vm-memory:0.9.0 --precise 0.8.0
. And we have to lock thelinux-loader
as well. But when my-lib is released, it still can't work.Solution
According to cargo recommendations:
Use caret requirements for dependencies, such as
1.2.3
, for most situations. This ensures that the resolver can be maximally flexible in choosing a version while maintaining build compatibility.And most open sources also use the SemVer version requirement(
x.y.z
), which is equivalent to Caret requirements(^x.y.z
). Mentioned in document specifying-dependencies:The SemVer version requirement can solve the problems mentioned earlier.
linux-loader 0.5.x
corresponds tovm-memory 0.9.x
, x upgrade does not break compatibility either.Drawbacks
Required Work
Progress
Thanks.