cargo upgrade should default to --skip-compatible

[djc]

For library crates, updating all dependency requirements in Cargo.toml to the latest semver-compatible versions is harmful to the ecosystem, as this makes it harder to resolve versions in case of for example yanking. I was already using --skip-compatible for my project, but just noticed that another library crate used cargo upgrade to force dependency upgrades this way, making it impossible to use the latest version of that crate after the latest futures version was yanked.

[epage]

Been thinking about this more and I think it makes sense to make it the default. The main question is how to present that to the user.

When looking at the behavior of cargo upgrade, I also realized the default behavior has a lot of overlap with --to-lockfile. We actually have --skip-compatible and --to-lockfile conflict with each other. This got me thinking that maybe we make --skip-compatible the default and --to-lockfile is the only way to force upgrading compatible fields.

Another challenge is we also want to preserve the precision but --skip-compatible and precision preservation are difficult to get to work together.

[epage]

Based on the feedback, I'm considering reverting this.

If I understood a comment from the Issue's author, it sounds like they've changed their mind

(I also think we should optimize for applications more than libraries, similar to how cargo init has already decided that --bin should be the default over --lib.)

[epage]

See #786

[djc]

As a reviewer of application PRs, I would dislike PRs that mix incompatible updates and compatible updates to Cargo.toml in the same commit, because that makes it very hard to distinguish the two cases, which IMO are very different. But I definitely think it would make sense to merge cargo upgrade functionality into cargo update, in which case some kind of option would be needed anyway.

(I personally don't see it make sense to deprecate update because that seems to cause much more churn for the larger ecosystem compared to deprecating upgrade and merging it into update.)

[epage]

As a reviewer of application PRs,

Could you add this to the thread?

(I personally don't see it make sense to deprecate update because that seems to cause much more churn for the larger ecosystem compared to deprecating upgrade and merging it into update.)

In general, we've been running into limitations with compatibility. Simple cargo-upgrade operations are becoming a soup of cargo-update flags (cargo update --incompatible --save just to get the old cargo upgrade behavior, not even getting into split use cases like yours)

So we're having to balance the ecosystem churn with usability and workflows.