rust-lang/cargo · error · anyhow::Error

lock file version `{current_version:?}` requires `-Znext-loc

Error message

lock file version `{current_version:?}` requires `-Znext-lockfile-bump`

What it means

Cargo.lock carries a version tag. If the on-disk version is newer than the maximum stable version the running cargo understands, write_pkg_lockfile refuses to proceed unless `-Znext-lockfile-bump` is enabled (lockfile.rs:86). This usually means the lockfile was produced by a newer/nightly cargo.

Source

Thrown at src/ops/lockfile.rs:86

        );
    }

    // While we're updating the lock file anyway go ahead and update its
    // encoding to whatever the latest default is. That way we can slowly roll
    // out lock file updates as they're otherwise already updated, and changes
    // which don't touch dependencies won't seemingly spuriously update the lock
    // file.
    let default_version = ResolveVersion::with_rust_version(ws.lowest_rust_version());
    let current_version = resolve.version();
    let next_lockfile_bump = ws.gctx().cli_unstable().next_lockfile_bump;
    tracing::debug!("lockfile - current: {current_version:?}, default: {default_version:?}");

    if current_version < default_version {
        resolve.set_version(default_version);
        out = serialize_resolve(resolve, orig.as_deref());
    } else if current_version > ResolveVersion::max_stable() && !next_lockfile_bump {
        // The next version hasn't yet stabilized.
        anyhow::bail!("lock file version `{current_version:?}` requires `-Znext-lockfile-bump`")
    }

    if !lock_root.as_path_unlocked().exists() {
        lock_root.create_dir()?;
    }

    // Ok, if that didn't work just write it out
    lock_root
        .open_rw_exclusive_create(LOCKFILE_NAME, ws.gctx(), "Cargo.lock file")
        .and_then(|mut f| {
            f.file().set_len(0)?;
            f.write_all(out.as_bytes())?;
            Ok(())
        })
        .with_context(|| {
            format!(
                "failed to write {}",
                lock_root.as_path_unlocked().join(LOCKFILE_NAME).display()

View on GitHub (pinned to 0e07a15537)

Solutions

1. Upgrade your toolchain to match the cargo that wrote the lockfile (e.g. `rustup update`).
2. If you intentionally use the newer format, run with `-Znext-lockfile-bump` (nightly only).
3. Downgrade the lockfile by deleting it and regenerating with your current stable cargo (may change resolved versions).

Example fix

# before
$ cargo build
error: lock file version `V4` requires `-Znext-lockfile-bump`

# after - upgrade toolchain to one that understands the version
$ rustup update stable
$ cargo build
# or, on nightly with the new format:
$ cargo +nightly build -Znext-lockfile-bump

# Check the lockfile version against your cargo's supported version:
if grep -q '^version' Cargo.lock 2>/dev/null; then
  # If build fails on version, upgrade toolchain first:
  rustup update stable || true
fi
cargo build || cargo +nightly build -Znext-lockfile-bump

When it happens

Trigger: Opening/building a project whose Cargo.lock was written by a newer cargo (or nightly with next-lockfile-bump) using an older stable cargo.

Common situations: Downgrading the rust toolchain; teammates on different rustup versions; lockfile committed from a nightly CI.

Related errors

• lock file version `{n}` requires `-Znext-lockfile-bump`
• not implemented
• invalid character `+` in dependency name: `+{toolchain}`
• invalid character `+` in package name: `+{toolchain}` Us
• missing crate name before '@'

AI-assisted analysis of rust-lang/cargo@0e07a15537 (2026-08-06). Data as JSON: /data/errors/c0b72f5da11c706d.json. Report an issue: GitHub.