Bump to version 8.0.0-rc.1 - #29918
Merged
Merged
Conversation
Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
The in-flight recipes were written when the next release was expected to be 0.18.0. This release is the transition onto the v8 RC line, so the step users actually take is 0.17 to 8.0 — rename both directories, correct their `to:` frontmatter, and repoint the recipe links in the release notes and changelog. Both upgrade skills build their chain by one-minor arithmetic, which cannot express this step; note that the directories present are the source of truth for what the steps are. Refs: TML-3170 Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
The before/after snippet used an accessor shape that does not exist (db.public.Group). Use the collection + include-reducer form the integration tests actually exercise. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
📝 WalkthroughWalkthroughThe pull request prepares the monorepo for ChangesRelease documentation and upgrade guidance
Release-candidate coverage handling
Workspace version alignment
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant PackageManifests
participant UpgradeCoverage
participant UpgradeSkills
participant ReleaseDocs
PackageManifests->>ReleaseDocs: Publish v8.0.0-rc.1 version and change documentation
UpgradeCoverage->>UpgradeSkills: Resolve RC transition directories
UpgradeSkills->>ReleaseDocs: Apply RC upgrade instructions
UpgradeCoverage->>PackageManifests: Validate RC package and upgrade coverage
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
prisma-next
@prisma/orm-extension-arktype-json
@prisma/orm-extension-middleware-cache
@prisma/orm-extension-paradedb
@prisma/orm-extension-pgvector
@prisma/orm-extension-postgis
@prisma/orm-extension-supabase
@prisma/orm-family-mongo
@prisma/orm-family-sql
@prisma/orm-framework
@prisma/orm-mongo
@prisma/orm-postgres
@prisma/orm-sqlite
@prisma/orm-target-mongo
@prisma/orm-target-postgres
@prisma/orm-target-sqlite
@prisma/orm-toolchain
commit: |
Contributor
size-limit report 📦
|
Contributor
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
packages/3-extensions/pgvector/package.json (1)
46-48: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove the package-local
vitestdependency.Internal packages must use the root-level Vitest installation. Remove
"vitest": "catalog:"from this manifest.Based on learnings: “do not declare vitest in package.json devDependencies for internal packages.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/3-extensions/pgvector/package.json` around lines 46 - 48, Remove the package-local "vitest": "catalog:" entry from the devDependencies in the package manifest, leaving the root-level Vitest installation as the only dependency source.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CHANGELOG.md`:
- Around line 9-11: Update the release summary in CHANGELOG.md lines 9-11 and
docs/releases/v8.0.0-rc.1.md lines 1-3 together so both accurately reflect the
four fix bullets, using the same corrected wording in each file.
In `@docs/releases/v8.0.0-rc.1.md`:
- Line 19: Add the same sentence after the contract note in
docs/releases/v8.0.0-rc.1.md at line 19 and CHANGELOG.md at line 27, stating
that an undeclared aggregate operation/input codec pair is rejected before
execution with ORM.AGGREGATE_UNSUPPORTED and must not be used as a runtime
fallback.
In `@skills/prisma-next-upgrade/SKILL.md`:
- Around line 65-66: Update the default-target wording in
skills/prisma-next-upgrade/SKILL.md:53 and
skills/prisma-next-upgrade/SKILL.md:65-66 to describe npm dist-tags.latest as
including release candidates, or change the lookup to a stable-only source.
Apply the same correction in skills/prisma-8-extension-upgrade/SKILL.md:50 and
skills/prisma-8-extension-upgrade/SKILL.md:62-63, keeping the documented
upgrade-chain guidance unchanged.
---
Nitpick comments:
In `@packages/3-extensions/pgvector/package.json`:
- Around line 46-48: Remove the package-local "vitest": "catalog:" entry from
the devDependencies in the package manifest, leaving the root-level Vitest
installation as the only dependency source.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: e2f3cc0a-a942-40de-83e4-2eb447b06c29
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (118)
CHANGELOG.mdapps/lsp-playground/package.jsonapps/telemetry-backend/package.jsondocs/releases/v8.0.0-rc.1.mdexamples/bundle-size/package.jsonexamples/bundle-size/src/mongo/package.jsonexamples/bundle-size/src/postgres/package.jsonexamples/mongo-blog-leaderboard/package.jsonexamples/mongo-demo/package.jsonexamples/multi-extension-monorepo/package.jsonexamples/paradedb-demo/package.jsonexamples/prisma-8-cloudflare-worker/package.jsonexamples/prisma-8-demo-sqlite/package.jsonexamples/prisma-8-demo/package.jsonexamples/prisma-8-postgis-demo/package.jsonexamples/react-router-demo/package.jsonexamples/retail-store/package.jsonexamples/supabase/package.jsonpackage.jsonpackages/0-config/tsconfig/package.jsonpackages/0-config/tsdown/package.jsonpackages/0-shared/extension-author-tools/package.jsonpackages/0-shared/publish-surface/package.jsonpackages/1-framework/0-foundation/contract/package.jsonpackages/1-framework/0-foundation/utils/package.jsonpackages/1-framework/1-core/config/package.jsonpackages/1-framework/1-core/errors/package.jsonpackages/1-framework/1-core/framework-components/package.jsonpackages/1-framework/1-core/operations/package.jsonpackages/1-framework/1-core/ts-render/package.jsonpackages/1-framework/2-authoring/contract/package.jsonpackages/1-framework/2-authoring/ids/package.jsonpackages/1-framework/2-authoring/psl-parser/package.jsonpackages/1-framework/2-authoring/psl-printer/package.jsonpackages/1-framework/3-tooling/cli-telemetry/package.jsonpackages/1-framework/3-tooling/cli/package.jsonpackages/1-framework/3-tooling/config-loader/package.jsonpackages/1-framework/3-tooling/emitter/package.jsonpackages/1-framework/3-tooling/language-server/package.jsonpackages/1-framework/3-tooling/migration/package.jsonpackages/1-framework/3-tooling/vite-plugin-contract-emit/package.jsonpackages/2-mongo-family/1-foundation/mongo-codec/package.jsonpackages/2-mongo-family/1-foundation/mongo-contract/package.jsonpackages/2-mongo-family/1-foundation/mongo-value/package.jsonpackages/2-mongo-family/2-authoring/contract-psl/package.jsonpackages/2-mongo-family/2-authoring/contract-ts/package.jsonpackages/2-mongo-family/3-tooling/emitter/package.jsonpackages/2-mongo-family/3-tooling/mongo-schema-ir/package.jsonpackages/2-mongo-family/4-query/query-ast/package.jsonpackages/2-mongo-family/5-query-builders/orm/package.jsonpackages/2-mongo-family/5-query-builders/query-builder/package.jsonpackages/2-mongo-family/6-transport/mongo-lowering/package.jsonpackages/2-mongo-family/6-transport/mongo-wire/package.jsonpackages/2-mongo-family/7-runtime/package.jsonpackages/2-mongo-family/9-family/package.jsonpackages/2-sql/1-core/contract/package.jsonpackages/2-sql/1-core/errors/package.jsonpackages/2-sql/1-core/operations/package.jsonpackages/2-sql/1-core/schema-ir/package.jsonpackages/2-sql/2-authoring/contract-psl/package.jsonpackages/2-sql/2-authoring/contract-ts/package.jsonpackages/2-sql/3-tooling/emitter/package.jsonpackages/2-sql/4-lanes/query-builder/package.jsonpackages/2-sql/4-lanes/relational-core/package.jsonpackages/2-sql/4-lanes/sql-builder/package.jsonpackages/2-sql/5-runtime/package.jsonpackages/2-sql/9-family/package.jsonpackages/3-extensions/arktype-json/package.jsonpackages/3-extensions/middleware-cache/package.jsonpackages/3-extensions/mongo/package.jsonpackages/3-extensions/paradedb/package.jsonpackages/3-extensions/pgvector/package.jsonpackages/3-extensions/postgis/package.jsonpackages/3-extensions/postgres/package.jsonpackages/3-extensions/sql-orm-client/package.jsonpackages/3-extensions/sqlite/package.jsonpackages/3-extensions/supabase/package.jsonpackages/3-mongo-target/1-mongo-target/package.jsonpackages/3-mongo-target/2-mongo-adapter/package.jsonpackages/3-mongo-target/3-mongo-driver/package.jsonpackages/3-targets/3-targets/postgres/package.jsonpackages/3-targets/3-targets/sqlite/package.jsonpackages/3-targets/6-adapters/postgres-codec-testkit/package.jsonpackages/3-targets/6-adapters/postgres/package.jsonpackages/3-targets/6-adapters/sqlite-codec-testkit/package.jsonpackages/3-targets/6-adapters/sqlite/package.jsonpackages/3-targets/7-drivers/postgres/package.jsonpackages/3-targets/7-drivers/sqlite/package.jsonpackages/9-public/@prisma/orm-extension-arktype-json/package.jsonpackages/9-public/@prisma/orm-extension-middleware-cache/package.jsonpackages/9-public/@prisma/orm-extension-paradedb/package.jsonpackages/9-public/@prisma/orm-extension-pgvector/package.jsonpackages/9-public/@prisma/orm-extension-postgis/package.jsonpackages/9-public/@prisma/orm-extension-supabase/package.jsonpackages/9-public/@prisma/orm-family-mongo/package.jsonpackages/9-public/@prisma/orm-family-sql/package.jsonpackages/9-public/@prisma/orm-framework/package.jsonpackages/9-public/@prisma/orm-mongo/package.jsonpackages/9-public/@prisma/orm-postgres/package.jsonpackages/9-public/@prisma/orm-sqlite/package.jsonpackages/9-public/@prisma/orm-target-mongo/package.jsonpackages/9-public/@prisma/orm-target-postgres/package.jsonpackages/9-public/@prisma/orm-target-sqlite/package.jsonpackages/9-public/@prisma/orm-toolchain/package.jsonpackages/9-public/prisma-next/package.jsonskills/prisma-8-extension-upgrade/SKILL.mdskills/prisma-8-extension-upgrade/upgrades/0.17-to-8.0/instructions.mdskills/prisma-next-upgrade/SKILL.mdskills/prisma-next-upgrade/upgrades/0.17-to-8.0/instructions.mdtest/e2e/framework/package.jsontest/e2e/framework/test/fixtures/package.jsontest/e2e/framework/test/sqlite/fixtures/package.jsontest/integration/package.jsontest/integration/test/cli-journeys/package.jsontest/integration/test/fixtures/cli/cli-e2e-test-app/package.jsontest/integration/test/fixtures/cli/cli-integration-test-app/package.jsontest/integration/test/fixtures/cli/cli-test-app/package.jsontest/utils/package.json
parseVersion() discarded the pre-release suffix, so every upgrade-instructions transition directory was keyed on major.minor. The whole v8 release-candidate line lives inside the 8.0.0 minor, so every RC transition collapsed onto the same label: an rc.1 -> rc.2 release asked for `8.0-to-8.1`, a directory named for a minor bump that never happens on the RC line. Since a version bump rewrites every package.json under examples/ and packages/3-extensions/, the coverage rule fires on every release, so every RC release PR would have failed. A version now carries an `rc` counter (null for stable versions and for any other pre-release suffix such as -dev.N), and the name a version contributes to a transition directory is its minor when stable and its full version when it is a release candidate. So the chain across the RC line reads `0.17-to-8.0.0-rc.1`, `8.0.0-rc.1-to-8.0.0-rc.2`, ... , `8.0.0-rc.N-to-8.0`. RC counters are never chained arithmetically: one release is one step. Two stable versions produce byte-identical labels to before. The in-flight directory while main sits on rc.N is `8.0.0-rc.N-to-8.0.0-rc.N+1`, which is exactly the directory the rc.N -> rc.N+1 release PR requires - the same relationship minors already had. Renames the in-flight recipes to 0.17-to-8.0.0-rc.1 in both upgrade skills and repoints the release-notes and CHANGELOG links. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
…wards The stable path already throws when head is behind prev, so refs passed out of order fail loudly. The RC path silently produced a backwards label (8.0.0-rc.4-to-8.0.0-rc.2). Apply the same rule. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/check-upgrade-coverage.mjs`:
- Around line 229-238: Update the RC range validation in the version-comparison
flow around versionSegment so major, minor, and patch are compared before RC
counters, with the counter compared only when the base versions match; preserve
chronological ordering across differing bases. Add regression cases in
scripts/check-upgrade-coverage.test.mjs: one where a later base resets to a
lower RC counter and one where an earlier base has a higher RC counter, covering
both affected sites.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: 26ed2474-24eb-44b1-8199-985c888bdf9e
📒 Files selected for processing (9)
CHANGELOG.mddocs/releases/v8.0.0-rc.1.mdscripts/check-upgrade-coverage.mjsscripts/check-upgrade-coverage.test.mjsskills-contrib/record-upgrade-instructions/SKILL.mdskills/prisma-8-extension-upgrade/SKILL.mdskills/prisma-8-extension-upgrade/upgrades/0.17-to-8.0.0-rc.1/instructions.mdskills/prisma-next-upgrade/SKILL.mdskills/prisma-next-upgrade/upgrades/0.17-to-8.0.0-rc.1/instructions.md
🚧 Files skipped from review as they are similar to previous changes (3)
- skills/prisma-8-extension-upgrade/SKILL.md
- CHANGELOG.md
- docs/releases/v8.0.0-rc.1.md
wmadden
approved these changes
Aug 7, 2026
…n guard - Correct the summary fix count in the notes and changelog, and say that an aggregate the target does not declare is rejected before execution with ORM.AGGREGATE_UNSUPPORTED rather than only typed away. - Both upgrade skills said `dist-tags.latest` resolves the latest stable; on the RC line latest tracks 8.0.0-rc.N, so say so. - Order the reversed-range guard by full semver precedence: the RC counter resets on each base version, so 8.0.1-rc.1 is newer than 8.0.0-rc.9 and must not be read as reversed. Refs: TML-3170 Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Linked issue
Refs TML-3170 — this is the release that starts the v8 RC line the pipeline work in #29899 prepared.
Summary
0.17.0→8.0.0-rc.1. This is the one-time transition onto the v8 release-candidate line: there are no further0.xminors, and subsequent releases advance the counter (8.0.0-rc.2,rc.3, …). Policy:docs/oss/versioning.md.Merging this PR ships the release. The push to
maincarries the bumped rootversion, thePublish to npmworkflow detects the change and publishes8.0.0-rc.1under dist-taglatest, and a matching GitHub Release — marked pre-release, because the version is on the RC line — is created withdocs/releases/v8.0.0-rc.1.mdas its body verbatim. No separate dispatch step.Review surface
docs/releases/v8.0.0-rc.1.mdis the human-review surface — it becomes the public Release body. It covers the RC-line transition (including thatnpm updatemoves nobody onto the RC, since^0.xranges can't match a pre-release), two breaking changes, one feature, and four fixes drawn from the 14 PRs merged sincev0.17.0.What each commit does
chore(release): bump to 8.0.0-rc.1pnpm bump-versionacross 113 manifests plus the lockfile. Version fields and internalworkspace:<version>specifiers only.docs(release): add release notes for v8.0.0-rc.1CHANGELOG.mdentry.chore(release): relabel the in-flight upgrade recipes 0.17-to-8.0docs(release): ground the aggregate example in the real ORM surfaceNotes for the reviewer
0.17-to-0.18→0.17-to-8.0. They were authored when the next release was expected to be0.18.0; the step users actually take is now0.17→8.0, which is also whatcheck:upgrade-coveragerequires once the bump crosses a major. The recipe contents are unchanged apart from theto:frontmatter, and the links in the notes and changelog were repointed to match. Both upgrade skills build their chain by one-minor arithmetic, which can't express this step, so each gained a line saying the directories present are the source of truth.SqlQueryableis exported and anyone implementing or wrapping a SQL driver must change; the ticket describes it as substrate-only with no ORM-visible behavior change, and the entry says so explicitly. If the custom-driver audience isn't considered real yet, that entry can be demoted to Features.update()/delete()docs that read as if they batch — no behavior changed, but say the word and it can be added as a documentation line under Fixes.Testing performed
pnpm check:release-notes --mode pr,pnpm check:upgrade-coverage --mode pr,pnpm check:publish-deps— all pass.pnpm test:scripts— 368 tests, 0 failures.package.jsonorpnpm-lock.yaml; the lockfile diff isspecifier: workspace:<old> → workspace:<new>lines only, with no external-resolution churn.SqlQueryablebefore/after matchesdriver-types.tsatv0.17.0and at HEAD, and the include-reducer result shape matches the assertions intest/integration/test/sql-orm-client/include.test.ts.Skill update
n/a — internal only. No user-facing CLI/API surface changes in the bump itself; the two upgrade skills' chain-construction note is a docs correction that follows from the relabel.
Checklist
git commit -s) per the DCO.n/a— release bump plus release notes; no behavioural delta).docs/oss/versioning.md.Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Update: the transition machinery is now RC-aware
Review of the first pass caught that the upgrade-instructions machinery was keyed on
major.minor, and the whole RC line lives inside one minor. Every RC transition collapsed to the same wrong label:0.17.0 → 8.0.0-rc.10.17-to-8.00.17-to-8.0.0-rc.18.0.0-rc.1 → 8.0.0-rc.28.0-to-8.18.0.0-rc.1-to-8.0.0-rc.28.0.0-rc.1 → 8.0.0-rc.78.0-to-8.18.0.0-rc.1-to-8.0.0-rc.78.0.0-rc.7 → 8.0.0final8.0-to-8.18.0.0-rc.7-to-8.0This was not cosmetic. A version bump rewrites every
examples/**andpackages/3-extensions/**manifest, so the coverage rule fires on every release — meaning every future RC release PR would have failed the same way this one first did, and the only way to satisfy it would have been to create a directory named for a minor bump that never happens. Users upgradingrc.1 → rc.5would also have found no recipes, which is exactly when they need them, since RC releases may carry breaking changes.A version's transition segment is now
major.minorfor a stable release and the fullmajor.minor.patch-rc.Non the RC line. The in-flight directory whilemainsits onrc.Nis8.0.0-rc.N-to-8.0.0-rc.N+1, which is precisely the coverage directory therc.N → rc.N+1release PR then requires — the same self-consistent relationship minors already had. Stable-to-stable behavior is byte-identical, asserted against the historical labels. A reversed RC range now throws, matching the stable path.The in-flight recipes on this branch were relabelled to
0.17-to-8.0.0-rc.1to match, and both upgrade skills' chain guidance now states the real rule (steps come from the directories present; on the RC line a step is one RC, not one minor).Verification after the change
pnpm test:scripts— 385 tests, 0 failures.pnpm check:upgrade-coverage --mode pr— pass.node scripts/check-upgrade-coverage.mjs --mode publish --prev v0.17.0 --head release/8.0.0-rc.1— pass (this is the check that runs onmainafter merge).pnpm check:release-notes --mode pr,node scripts/validate-skills.mjs— pass.One more for the reviewer
The recipe bodies still carried the pre-v8 numbering in their headings and prose ("0.17 → 0.18", references to 0.18 as the release introducing the aggregate change — a version that was never published). Those were rewritten to
8.0.0-rc.1, since the recipes are consumer-facing and the directory was being renamed around them.