Add --preserve-precision flag to cargo-upgrade

[smoelius]

This is continuation of a discussion starting here: #126 (comment).

Currently, when cargo upgrade updates a dependency requirement, it does so with full precision, i.e., specifying the major, minor, and patch versions. The proposal is to add a flag --preserve-precision that, when set, causes the new requirement to use the same components as the existing requirement.

For example, consider:

itertools = "0.8"

As of this writing, cargo upgrae turns this into:

itertools = "0.10.3"

The proposal is that cargo upgrade --preserve-precision would turn this into:

itertools = "0.10"

This flag would make cargo upgrade more flexible, and thereby applicable to more projects, e.g., projects whose developers (for whatever reason) prefer not to rely on some dependency with full precision.

@epage noted that similar logic is already present in cargo-set-version.

Thanks, @epage and @kornelski, for providing feedback on this idea already.

[epage]

Some of my concerns for cargo-add being configurable apply

• A patch release can contain code that will break you if downgrading. Setting it to the version the user will rely on in their lock file is least likely to run into problems

• I do not think this should be in a persistent configuration, its too situational.

• I do not think this should be in the CLI, its too specialized

• Configuring this well (including handle "0.x.y" releases), would be complicated

• The user always has the workaround of specifying the version, manually adding it their manifest, or just going into the manifest and trimming it

I'll say that my opinion is less strong for preserving existing precision in cargo-upgrade than having configurable precision in cargo-add. Even better if we have consensus one way or the other and don't need a flag to control this.

I do wonder if trends towards preferring a specific precision will die down with further adoption of cargo-add once its built-in to cargo.

[epage]

Ideally, we always specify at least the last working version. Without -Z minimal-versions being adopted, this is most likely whatever is in your lock file (or latest version without a lock file) since that is all that is being tested.

However, I would say version requirements should not be "always latest". We might want to upgrade binaries on a regular cadence but ideally, we don't update version requirements more than needed. It can cause extra build churn and cause conflicts unnecessarily (most patches are not critical)

[epage]

With all of that said, I would be open to seeing a PR that switches cargo-upgrade to use cargo-set-versions logic for us to evaluate and see how it works in practice.