Repository navigation
Discuss: not update Cargo.toml minor/patch version? #14962
Description
Activity
From the discussion, I can see the main motivation is to have reproducible build (agains near latest dependencies) in CI. To achieve this, Cargo.lock (updated by bot) is enough.
Another reason we always increase Cargo.toml versions of submodules is that we don't test DataFusion building with other versions.
For example, if one of the dependencies like
arrowreleases a new minor version that has a new function, and then we update DataFusion to use that new function, then DataFusion actually really does require the newer versionWe don't spend much time
Whether or not updating Cargo.toml means whether or not force downstream users to use only the latest dependency versions. Personally I prefer a more tolerable version range, so that downstream can update deps 1 by 1 and audit each dep's changes.
I think having a wider version range would be valuable and make DataFusion easier to use by downstream projects as well. The key thing is to figure out how to test that the ranges encoded in Cargo.toml are actually accurate
Reacted by xxchanThere's a flag
direct-minimal-versionshttps://doc.rust-lang.org/cargo/reference/unstable.html#direct-minimal-versions which fits perfectly for minimal version testing,but maybe has some minor problems though rust-lang/cargo#5657 (comment)In iceberg-rust, we currently use it to do MSRV test together with min version deps test (some deps cannot be built on MSRV in newer toolchain versions )
Reacted by Andrew Lamb@logan-keede filed a related ticket / discussion
I think having a wider version range would be valuable and make DataFusion easier to use by downstream projects as well. The key thing is to figure out how to test that the ranges encoded in Cargo.toml are actually accurate
If we allow/support a version range, we should test with lowest versions and highest versions. If both version-sets pass the tests, we can 🤞-project that any allowed versions pass the test.
We don't spend much time
I agree the project time budget is a constrain.
Reacted by Andrew Lamb
Hi, I see we've checked in
Cargo.lockrecently #14135, and I think it's good!But I'm not sure whether this was discussed: what about not updating
Cargo.toml(for minor/patch versions), but onlyCargo.lock?From the discussion, I can see the main motivation is to have reproducible build (agains near latest dependencies) in CI. To achieve this,
Cargo.lock(updated by bot) is enough.Whether or not updating
Cargo.tomlmeans whether or not force downstream users to use only the latest dependency versions. Personally I prefer a more tolerable version range, so that downstream can update deps 1 by 1 and audit each dep's changes.FYI in iceberg-rust, we have similar discussions on this topic, and we prefer to have a wider range of versions support, to allow users to choose their dep version (by not updating Cargo.toml too often) https://lists.apache.org/thread/pv3onm41229lovs1odqg94fdc60wcp73