You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Cargo will try to use the newest version of dependencies when you invoke cargo update or just build for the first time. This is a pain when you're trying to write a package, as it means the version of dependencies listed in the manifest doesn't necessarily match the version of dependencies that are being tested/developed against.
As such, it would be very convenient if there was a shorthand command or switch that downgraded all dependencies of the current package to the earliest possible versions. For bonus points, it should signal an error if the version specified by a ^ (and possibly >=) constraint is not selectable (i.e. "you say I should be able to select plimsor="1.2.6", but I can't actually do so). Double bonus points for some persistent per-package option that makes this the default and/or prevents implicitly updating dependencies with some explicit override.
This should help keep package authors honest about what dependency versions their code actually works with.
The text was updated successfully, but these errors were encountered:
Currently, Cargo will try to use the newest version of dependencies when you invoke
cargo update
or just build for the first time. This is a pain when you're trying to write a package, as it means the version of dependencies listed in the manifest doesn't necessarily match the version of dependencies that are being tested/developed against.As such, it would be very convenient if there was a shorthand command or switch that downgraded all dependencies of the current package to the earliest possible versions. For bonus points, it should signal an error if the version specified by a
^
(and possibly>=
) constraint is not selectable (i.e. "you say I should be able to selectplimsor="1.2.6"
, but I can't actually do so). Double bonus points for some persistent per-package option that makes this the default and/or prevents implicitly updating dependencies with some explicit override.This should help keep package authors honest about what dependency versions their code actually works with.
The text was updated successfully, but these errors were encountered: