« Changelog History


cargo-edit v0.11.0 Release Notes

Release Date: 2022-09-14 // over 1 year ago

  • 🚀 This release is another step in our effort to find the appropriate cargo ⬆️ upgrade workflow for merging into cargo.

    This new iteration is modeled on the idea "if we started from scratch, what ⚡️ would cargo update look like?". Besides getting us to think outside ⚡️ the box, I hope that we can deprecate cargo update and replace it with cargo ⬆️ upgrade (caution: this has not been passed by the cargo team). We need 👀 runtime with the proposed behavior with feedback to see how well the idea works 🗄 in theory and if it justifies the ecosystem churn of deprecating cargo ⚡️ update.

    🚀 More concretely, the approach taken in this release is a cargo update-like 🔒 command that implicitly modifies Cargo.lock.

    To this end

    • ⬆️ cargo upgrade now works on the whole workspace exclusively
      • This also resolves confusion over --package, --exclude, and the positional PKGID argument
      • This also removes any UI barriers for supporting workspace inheritance coming in 1.64
    • ⚡️ cargo upgrade -p [email protected] will act as if cargo update -p serde --precise 1.0.100 was performed
    • ⬆️ Compatible versions are upgraded by default
      • Pass --incompatible or --pinned to upgrade to incompatible versions
      • Disable the default with --compatible false
      • See this PR for context on the trade offs

    A side benefit of this approach is that users will get an approximation of minimal-version resolution so long as they stay within cargo add and cargo 🔒 upgrade and commit their Cargo.lock file.

    Please include in any ⬆️ feedback:

    • An evaluation of current behavior that takes into account the exiting "care abouts" or any additional we don't have listed yet
    • 👍 An evaluation of how existing or new alternatives would better fit the full set of care abouts

    💥 Breaking Changes

    ⬆️ upgrade

    • ⬆️ Compatible versions are upgraded by default, with opt-out via --compatible false
    • ⬆️ Pinned dependencies will be upgraded to compatible versions when --compatible true, reserving --pinned for incompatible upgrades
    • Incompatible versions require opting in with -i / --incompatible
    • 🔒 When a version requirement is fully specified, the lock version will modified to use that version
    • Exclusively operate on the workspace
    • ⬆️ The positional argument for selecting dependencies to upgrade has moved to --package <NAME>
    • 📦 --package and --exclude now take crate names rather than dependencies names (matters when dependencies are renamed)

    🔋 Features

    ⬆️ upgrade

    • ⚡️ --recursive <true|false> for controlling how the lockfile is updated
    • ⚡️ Update git dependencies

    🛠 Fixes

    ⬆️ upgrade

    • 📌 Treat 3.2.x as pinned
    • ⚡️ Update lockfile in offline mode
    • Don't touch the lockfile in dry-run
    • ⬆️ Prefer preserving the original version requirement over compatible version upgrades (in cases where we don't know how to preserve the format)