TML-3439: A product release releases the CLI, so prisma@latest never pins an older ORM toolchain

.github/workflows/update-product-versions.yml

@@ -1,10 +1,10 @@
 name: Update product versions
 
 # When composer or prisma/prisma publish a release of a package this repo
-# depends on, this workflow moves the dependency and opens a pull
-# request; merging it ships a dev version of the CLI (operator rulings
-# 2026-08-13 and 2026-08-17; docs/oss/release-automation.md). Only a real
-# CLI release needs a human.
+# depends on, this workflow moves the dependency, bumps the CLI to its next
+# version and opens a pull request; merging it releases the CLI
+# (docs/oss/release-automation.md). A CLI shipped behind a product release
+# breaks every project on that release, so nobody has to remember to cut it.
 #
 # It follows each product's RELEASE tag, never `dev`. The dev channel
 # gets its dev builds from publish.yml's stamp instead, so what this
@@ -52,6 +52,8 @@ jobs:
         uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
         with:
           persist-credentials: false
+          # The release tags, to compare main's pins with the last release.
+          fetch-depth: 0
 
       - name: Set up pnpm
         uses: pnpm/action-setup@0e279bb959325dab635dd2c09392533439d90093 # v6.0.8
@@ -65,50 +67,53 @@ jobs:
         id: compare
         run: node scripts/update-product-versions.mjs --channel release
 
-      # `pnpm install --no-frozen-lockfile` scoped to the lockfile
-      # refresh: the edit touches two manifests, and the pull request must
-      # carry the matching lockfile or every CI job fails on
-      # --frozen-lockfile.
-      - name: Refresh the lockfile
+      - name: Bump the CLI version
+        id: bump
         if: ${{ steps.compare.outputs.changed == 'true' }}
         run: |
           corepack enable
-          pnpm install --lockfile-only --no-frozen-lockfile
+          pnpm bump-version
+          echo "version=$(node -p "require('./package.json').version")" >> "$GITHUB_OUTPUT"
 
       - name: Open the pull request with auto-merge
         if: ${{ steps.compare.outputs.changed == 'true' }}
         env:
           GH_TOKEN: ${{ secrets.DEPLOY_GITHUB_TOKEN }}
           SUMMARY: ${{ steps.compare.outputs.summary }}
+          VERSION: ${{ steps.bump.outputs.version }}
         run: |
           if [ -z "$GH_TOKEN" ]; then
             echo "::error::DEPLOY_GITHUB_TOKEN is not configured, so this workflow cannot open a pull request that triggers CI. See docs/oss/release-automation.md."
             exit 1
           fi
-          # An open pull request from an earlier run already carries these
-          # versions or is about to be superseded by this one. Close it
-          # rather than stacking a second: two open version updates race
-          # each other's auto-merge and one lands on a stale lockfile.
+          # Every open version update or release pull request bumps the same
+          # version this one does, so only one of them can merge.
+          COMMENT="Superseded by the automatic release $VERSION, which follows the products' released versions: $SUMMARY."
           gh pr list --state open --json number,headRefName \
             --jq '.[] | select(.headRefName | startswith("product-versions/")) | .number' \
             | while read -r number; do
             [ -n "$number" ] || continue
-            gh pr close "$number" \
-              --comment "Superseded by a newer product version update." \
-              --delete-branch
+            gh pr close "$number" --comment "$COMMENT" --delete-branch
+          done
+          gh pr list --state open --json number,title \
+            --jq '.[] | select(.title | startswith("Bump to version ")) | .number' \
+            | while read -r number; do
+            [ -n "$number" ] || continue
+            gh pr close "$number" --comment "$COMMENT"
           done
           BRANCH="product-versions/$(date -u +%Y%m%d%H%M%S)"
+          TITLE="Release $VERSION: follow the products' released versions: $SUMMARY"
           git config user.name "willbot"
           git config user.email "w.a.madden+machine@gmail.com"
           git checkout -b "$BRANCH"
-          git add packages/cli/package.json packages/prisma/package.json pnpm-lock.yaml
+          git add -u
           git commit -s --trailer "Signed-off-by: Will Madden <madden@prisma.io>" \
-            -m "Follow the products' released versions: $SUMMARY" \
-            -m "Opened automatically (update-product-versions.yml); merging ships a dev version of the CLI. A real release stays a human act."
+            -m "$TITLE" \
+            -m "Opened automatically (update-product-versions.yml); merging releases the CLI."
           git push "https://x-access-token:${GH_TOKEN}@github.com/${GITHUB_REPOSITORY}.git" "$BRANCH"
           PR_URL=$(gh pr create \
-            --title "Follow the products' released versions: $SUMMARY" \
-            --body "Opened automatically by update-product-versions.yml, following the products' release dist-tags ($SUMMARY). Merging publishes a \`dev\` version of the CLI; the conformance checks on this pull request are what stand between a product release and that dev build." \
+            --title "$TITLE" \
+            --body "Opened automatically by update-product-versions.yml, following the products' release dist-tags ($SUMMARY). Merging releases \`prisma@$VERSION\` under \`latest\`; the checks on this pull request are what stand between a product release and that CLI release." \
             --base main --head "$BRANCH")
           gh pr merge --auto --squash "$PR_URL"
           echo "Opened $PR_URL with auto-merge armed."

README.md

@@ -135,10 +135,7 @@ lockstep) is the release source of truth. The workflow publishes
 
 Release channels:
 
-- `latest`: releases on the Prisma 8 RC line (`8.0.0-rc.N`). A merged
-  `chore(release)` PR that bumps the root version (via `pnpm bump-version`)
-  publishes automatically; `workflow_dispatch` is the manual escape hatch and
-  the dry-run path.
+- `latest`: releases on the Prisma 8 RC line (`8.0.0-rc.N`). A merged PR that bumps the root version (via `pnpm bump-version`) publishes automatically: a maintainer's release PR, or the version-follow PR a product release opens; `workflow_dispatch` is the manual escape hatch and the dry-run path.
 - `dev`: latest successful `main` build. Every push to `main` that does not
   change the root version publishes `<base>-dev.N` under the `dev` dist-tag.
   Commit traceability comes from npm provenance and the GitHub Actions run.

docs/oss/release-automation.md

@@ -1,6 +1,6 @@
 # Release automation across the three repositories
 
-The unified CLI is assembled from three repositories. This page explains how a new product version reaches the CLI without anyone editing a file by hand, what the one shared secret is for, and how to repair the machinery when it stops.
+The unified CLI is assembled from three repositories. This page explains how a new product version reaches a released CLI without anyone editing a file or approving a release, what the one shared secret is for, and how to repair the machinery when it stops.
 
 | Repository | Publishes | Consumed by the CLI as |
 | --- | --- | --- |
@@ -16,9 +16,10 @@ A **release** of the CLI depends only on **released** versions of the products.
 
 1. The product repository's publish workflow finishes and sends a `repository_dispatch` event of type `product-published` to `prisma/prisma-cli`.
 2. [`update-product-versions.yml`](../../.github/workflows/update-product-versions.yml) runs [`scripts/update-product-versions.mjs`](../../scripts/update-product-versions.mjs), which asks the registry for each watched package's version at its **release** dist-tag and rewrites `packages/cli/package.json` and `packages/prisma/package.json` where they differ. Every watched package publishes its releases under `latest`, pre-release versions included: they are all new packages with no pre-8 audience to protect. Holding `latest` back behind `next` matters only for the bare `prisma` name, which this repository publishes and which still serves Prisma 7 there until the deliberate cutover. Each package carries a list of candidate tags rather than one name, most-preferred first, so a product moving where it publishes does not silently freeze the CLI on an old version — and a package that publishes none of its candidates fails the run instead of looking like "nothing to update".
-3. If anything changed, the workflow refreshes `pnpm-lock.yaml`, opens a pull request, and arms auto-merge. Any earlier open pull request from this workflow is closed first, so two of them cannot race each other onto a stale lockfile.
-4. The pull request runs the full quality and conformance checks. When they pass, it merges, and that push to `main` publishes a `dev` build of the CLI carrying the products' **dev** versions (the dev stamp in [`publish.yml`](../../.github/workflows/publish.yml) rewrites them for that run only).
-5. A real CLI release stays a human act: a maintainer cuts the `rc.N` bump, and that release ships the committed release versions.
+3. If any pin changed, or `main` holds pins the last release (its `v<version>` tag) did not ship, the workflow bumps the CLI to its next version with `pnpm bump-version` (which also refreshes `pnpm-lock.yaml`), opens a pull request titled `Release <version>: follow the products' released versions: ...`, and arms auto-merge. Every earlier open pull request from this workflow, and every open `Bump to version` release pull request, is closed first: each bumps the same version, so only one can merge.
+4. The pull request runs the full quality and conformance checks. When they pass and CodeRabbit approves it (the `main` ruleset requires one approving review), it merges, and that push to `main` changes the root version, so [`publish.yml`](../../.github/workflows/publish.yml) publishes the release under `latest` with the committed product versions, plus the usual `dev` build.
+
+A product release reaches a released CLI with no person in the loop, because a CLI left on an older product version breaks every project on the newer one: `prisma@8.0.0-rc.29` pinned `@prisma/orm-toolchain` 8.0.0-rc.21 for four days after the ORM's rc.22 shipped, while its release pull request waited for a review. A release for a change in this repository alone is still cut by a maintainer (see [versioning.md](versioning.md)). Everything on `main` ships with either kind of release, so `main` must always be releasable. Any commit that changes a product pin on `main`, by hand or not, is released by the next run.
 
 A **daily schedule** runs the same comparison, so a lost dispatch event delays an update by at most a day rather than indefinitely. `workflow_dispatch` runs it on demand.
 
@@ -40,7 +41,7 @@ One fine-grained personal access token, stored under the same secret name in all
 
 Only `prisma/prisma-cli` needs to be listed even though the secret lives in three repositories. In this repository the token pushes the branch and opens the pull request. In composer and prisma/prisma it only sends the `repository_dispatch` event *to* this repository, and that endpoint needs Contents write **on the target repository** — the same permission on the same one repository.
 
-Deliberately **not** granted: the Workflows permission. The pull request only ever touches the two manifests and the lockfile, so a change under `.github/workflows/` would be rejected — a useful limit on an unattended token.
+Deliberately **not** granted: the Workflows permission. The pull request only ever touches the files `pnpm bump-version` and `update-product-versions.mjs` write, so a change under `.github/workflows/` would be rejected — a useful limit on an unattended token.
 
 **When it expires** the workflow fails: an absent secret is reported as an error before anything else runs, and an expired one fails the first `git push` or `gh` call. The catch is *where* it fails — a scheduled run nobody is watching — so the visible symptom is stale versions rather than a red pull request, and the daily backstop cannot recover on its own until the token is replaced. Record the renewal date somewhere you will see it. To replace it, generate a new token with the table above and update the secret in all three repositories; nothing in any repository names the account, so no code changes.
 
@@ -71,7 +72,9 @@ A workflow step that must run should fail when its secret or token is missing, n
 | No pull request after a product release | Dispatch event not sent, or the token is missing or expired | The daily run will catch it up; check the product repository's notify step and the secret |
 | The workflow fails with "DEPLOY_GITHUB_TOKEN is not configured" | The secret is absent from this repository | Add it (see above) |
 | A pull request opens but never merges | Required checks failing | Read the checks — this is the automation working; a product release broke something |
-| Two open version-update pull requests | The close-the-previous step failed | Close the older one by hand; they race each other's lockfile |
+| Two open version-update pull requests | The close-the-previous step failed | Close the older one by hand; they race each other's version and lockfile |
+| Checks pass but the pull request does not merge | The `main` ruleset requires one approving review, which CodeRabbit gives; it commented or was rate-limited instead | Approve the pull request by hand |
+| `main` holds product pins no release shipped | A release took the version number before the follow pull request merged | The next run (the daily schedule at the latest) compares `main`'s pins with the last release's tag and opens a release for them; dispatch the workflow to do it now |
 | A published version never appears on the registry | npm accepted the publish but the version is not resolvable | The publish run polls for it and fails if it never appears; if that fails, re-dispatch the workflow — an already-published version is treated as done, so only the missing one publishes |
 | A release publish fails on the dev-build check | The committed pins are dev builds — a dev stamp was committed by mistake, or a product has no usable release | Run `node scripts/update-product-versions.mjs --channel release`; if that changes nothing, the product must publish a real release |