Recovering from a Failed Upgrade After Removing :clojure-version in Clojure 1.12

Restoring the Lockfile to a Verified State

To safely restore your project to a known-working state after a failed upgrade, you must eliminate the current resolution state and force a clean re-computation. Because tools.deps does not automatically regenerate the lockfile when deps.edn is modified, follow this sequence:

1. Revert deps.edn: Roll back your deps.edn file to the last known-good commit.
2. Purge the Cache: Delete the .cpcache/ directory. This removes the existing lockfiles and cached classpaths, preventing the tool from attempting to reconcile the failed upgrade state with the reverted configuration.
3. Regenerate: Run clojure -P to create a fresh lockfile based on the reverted deps.edn.
4. Verify: Run your test suite (e.g., clojure -M:test) to confirm the environment is stable before attempting the upgrade again.

Pinning Clojure Versions in 1.12+

With the removal of the :clojure-version key, Clojure is now treated as a standard dependency. To pin a specific version, add org.clojure/clojure directly to your :deps map.

{:deps
  {org.clojure/clojure {:mvn/version "1.12.0"}
    ;; other dependencies here
  }}

Note: Do not leave the old :clojure-version key in the file. While it is ignored in version 1.12 and later, keeping it creates configuration drift and confusion for other developers.

Guaranteeing Lockfile Consistency

To ensure the lockfile reflects your pinned dependencies across all environments without manual editing, use the following command pattern:

clojure -P -Sforce

The -P flag generates the lockfile, and -Sforce forces the re-computation of the classpath. This combination ensures that any changes to the :deps map—including the transition from :clojure-version to an explicit dependency—are fully realized in the lockfile.

Verification and Diagnostics

After running the recovery or upgrade, verify the resolved graph using:

clojure -Stree

Check the output to ensure org.clojure/clojure is listed at the expected version and that no conflicting transitive versions of the Clojure runtime are present. If you encounter a version conflict that -Sforce does not resolve, you may need to add a direct dependency for the conflicting transitive library to override the resolution.

Diagnostic Detail: If the above steps do not resolve the crash, please specify if you are using a custom :mvn/local-repo or an offline mirror, as this can interfere with how clojure -P fetches artifacts.