## At a glance

```bash
# before this PR merges
npm install prisma        # -> 7.9.1  (Prisma 7)
npm install prisma@next   # -> 8.0.0-rc.9

# after this PR merges
npm install prisma        # -> 8.0.0-rc.10  (the unified v8 CLI)
```

## The decision

We are cutting the bare `prisma` npm name over to the v8 line. Until
now, every 8.0.0-rc release published under the `next` dist-tag and
`latest` kept serving Prisma 7, so nobody landed on v8 without asking
for it. The operator ruled today (2026-08-25) that the RC line is ready
to be what a bare `npm install prisma` gets. The version number does not
change meaning: we stay on `8.0.0-rc.N` (this release is rc.10), and
GitHub Releases remain marked pre-release. Only the dist-tag policy
moves.

## How the flip actually happens

In this repo, merging a version-bump PR is the act that publishes: the
push to `main` carries a changed root version, and the publish workflow
ships it under the tag `releaseDistTag()` returns. This PR widens that
function so every release — RC or stable — publishes under `latest`.
**Merging this PR is therefore the cutover itself**: it bumps rc.9 →
rc.10 and the resulting publish moves `latest` on `prisma` and
`@prisma/cli` in one deliberate, reviewable act.

## What rc.10 ships (since rc.9)

- Config files evaluate correctly when the CLI is reached through pnpm
symlink layouts that are not realpath'd (#222) — previously every
config-reading command failed with `CLI.CONFIG_UNREADABLE` in those
setups.
- The engine's CI detector is exported and the skills staleness notice
uses it, so Jenkins/TeamCity/Azure pipelines stop seeing the notice in
their logs (#224).
- The `prisma init` scaffold fixes (#225).
- Current command-family releases, both peering the exact engine this
repo ships (`@prisma/cli-engine@0.2.3`), so one engine resolves per
install and the conformance exception list is empty again:
`@prisma/composer-cli@0.14.0` and `@prisma/orm-toolchain@8.0.0-rc.7`
(which carries the PostgreSQL temporal-codec representations and the
`limit`/`offset` pagination rename).

## What happens to the `next` tag and to v7 users

- `next` is retired: the publish path no longer moves it, and
`scripts/cutover-dist-tags.sh` (operator-run) removes it from all three
names and fixes the engine's stale tags. Text that says `prisma@next`
should move to plain `prisma` — after this merge they resolve the same
thing anyway, until the tag is removed.
- Existing v7 installs are untouched: lockfiles pin resolved versions,
and `prisma@7.9.1` stays installable by version. The v7 train's new
publish home (`prisma7`) is being handled separately and does not block
this.

## Alternatives considered

- **A one-off `workflow_dispatch` with `dist-tag: latest`** — moves
`latest` once, but every subsequent RC release would publish under
`next` again and leave `latest` stale on rc.10. The widened rule makes
the routine release path keep `latest` current.
- **Waiting for stable `8.0.0`** — the rollout plan always left the flip
timing to an operator judgement after an RC soak, not to the stable
release; the operator ruled the soak is over.
- **Keeping `next` synced to `latest`** — considered so existing
`prisma@next` instructions would keep resolving the newest release, and
dropped: re-pointing a tag on an already-published version cannot
authenticate over OIDC, and npm's granular tokens go no narrower than
package write — a standing sync would mean a standing publish-capable
token, defeating the repo's OIDC-only invariant. Retiring the tag is the
honest alternative.

## Verification

Script tests green (33/0 on determine-version-utils). Conformance with
the empty exception list: **5 subjects checked, nothing to report**, on
both the release and dev channels. Lint and the CLI/engine suites green.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

…ne@0.2.2 (prisma#30111)

prisma-cli published `@prisma/cli-engine@0.2.2`: config evaluation works
through pnpm symlink layouts that are not realpath'd
(prisma/prisma-cli#222) and the engine's CI detector is exported
(prisma/prisma-cli#224). The registry's 0.2.0 predates both; 0.2.1 is
skipped — no family released against it. `@prisma/orm-toolchain`
declares the engine as an exact peer, so it must release against the
engine version the `prisma` bin will ship.

- Every `@prisma/cli-engine` reference moves 0.2.0 → 0.2.2 (manifests,
fixtures, examples, the init-journey harness literal).
- `pnpm bump-version`: 8.0.0-rc.5 → 8.0.0-rc.6, stamped across the
workspace.
- Release notes at `docs/releases/v8.0.0-rc.6.md` (`check:release-notes
--mode pr` passes) plus the matching `CHANGELOG.md` entry, covering
prisma#30096 and prisma#30097 — the two PRs merged since rc.5 — and the engine move.
- `check:upgrade-coverage` passes in both modes.

Merging publishes the release under `latest`, which unblocks the
prisma-cli PR that pins it and removes the engine-transition exceptions.
The composer half of the train is prisma/composer#256.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Bundled `prisma-8` skills and upgrade guidance are now included in ORM
package tarballs.
  * Skill setup is now handled through `prisma init`.

* **Breaking Changes**
* PostgreSQL temporal columns now use explicit `Temporal` or text
representations instead of `Date`.
* `prisma orm init` no longer installs skills or supports
`--skip-skills`.

* **Documentation**
* Added `8.0.0-rc.6` release notes and upgrade instructions, including
contract artifact updates and temporal migration examples.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>