A release push also publishes a dev build - #241
Merged
Conversation
A push that bumps the root version used to publish only `<base>` under `latest`, so the release commit never reached the `dev` dist-tag. `dev` then sat on a build of the previous base until the next routine push; after 0.8.0 the stale tag still peered the broken @prisma/cli-engine@0.1.1 and blocked a prisma-cli release publish. determine-version.ts now plans the push publish through a pure planPushPublish helper that, on a release bump, also emits a devVersion output (`<base>-dev.N`, continuing the registry counter). The workflow gains a dev follow-up after the release steps: re-stamp with devVersion, rebuild, re-run check:publish-deps, publish under `dev`, and tag the commit. The follow-up only runs when devVersion is non-empty, which only a release push produces; dispatch semantics and the `latest` leg are unchanged. Every push to main now leaves `dev` on a build of that commit. Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
|
Important Review available on request
Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 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 |
wmadden
approved these changes
Aug 18, 2026
commit: |
Contributor
Author
|
Dry-run |
Merged
birhantprkc
pushed a commit
to birhantprkc/prisma
that referenced
this pull request
Aug 25, 2026
At a glance: after this change, a merged release PR leaves both dist-tags on the released base — ``` push to main bumping 8.0.0-rc.6 → 8.0.0-rc.7 publishes 8.0.0-rc.7 under latest (as before) then publishes 8.0.0-rc.7-dev.1 under dev (new) ``` **Decision:** the dev and release publishes are no longer alternatives. Every push to `main` publishes a `<base>-dev.N` build under `dev`; a version-changing push additionally publishes the release under `latest` first. Adopted from composer's model in prisma/composer#241 (prisma-cli made the identical change on 2026-08-18). Previously a release push skipped the dev leg, so `dev` sat on a dev build of the previous base until the next routine push. That staleness caused a real outage on 2026-08-25: after 8.0.0-rc.7 released, `dev` still pointed at `8.0.0-rc.6-dev.1`, whose `@prisma/orm-toolchain` peers `@prisma/cli-engine@0.2.2` while the CLI ships 0.2.3. prisma-cli's dev channel builds against this repo's `dev` tag with no fallback, so its conformance check failed with an engine-pin mismatch and blocked its release until the tag was moved by hand. How it works: `determine-version.ts` now emits a third output, `devVersion`, which is empty except on release pushes. The workflow gains a "dev follow-up" leg conditioned on it: re-stamp versions to `<base>-dev.N`, rebuild, re-run the version-sensitive dependency-specifier check, publish under `dev`, and create the lightweight `v<version>-dev.N` tag. The release steps already ran the full check battery against the same commit, so the follow-up repeats only the check the version stamp affects. Dev suffixes remain ephemeral CI stamps and are never committed. One deliberate deviation from composer's step ordering: the follow-up runs **before** the "Notify prisma-cli" step. That notification triggers prisma-cli's auto-repin, which builds its dev channel against this repo's `dev` tag — notifying before the follow-up would re-create the exact outage at notify time. The decision logic moved into a pure `planPushPublish` helper in `determine-version-utils.ts` (mirroring composer's), with unit tests covering the dev-only path, the release-plus-follow-up path, counter continuation, and the unreadable-previous-version fallback. `docs/oss/versioning.md`'s trigger-model and dist-tag sections are updated to match. Alternative considered: running the dev leg unconditionally *before* the release leg. Rejected to match composer's ordering — publishing the release first means `latest` never waits on the dev leg, and a failure in the follow-up leaves the release itself intact. 🤖 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** * Development builds are now published on every push to `main` under the `dev` tag. * Release pushes publish both the stable package and a corresponding development build. * Development version numbering continues correctly across releases. * Re-running a release publish also restores the associated development build. * **Documentation** * Updated versioning guidance to describe the new publishing behavior and release process. * **Tests** * Added coverage for development-only publishes, releases, version lookup failures, dry runs, and continued development numbering. <!-- 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>
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
2 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.
Problem
The publish workflow treated a push to
mainas either a dev publish or a release — never both. The commit that ships a release therefore never reached thedevdist-tag, anddevsat on a build of the previous base until the next routine push. This bit twice: after0.7.0,devstayed on0.6.0-dev.23for a day; after0.8.0, the staledevtag still peered the broken@prisma/cli-engine@0.1.1and blocked prisma-cli's8.0.0-rc.5publish. Design brief: prisma-cli#194; reference restructure: prisma-cli#195.Change
planPushPublish(new, pure, indetermine-version-utils.ts, tested): plans the publish for a push. On a release bump it returns the release version underlatestplus adevVersion(<base>-dev.N, continuing the registry counter — so a rerun after a partial failure advances rather than collides).determine-version.tsnow emits a third output,devVersion— empty on every event except a release push.publish.ymlappends a dev follow-up after the release steps, each step conditioned ondevVersion != '': re-stamp withset-version.ts, rebuild, re-runcheck:publish-deps(the only version-sensitive check; the release steps already ran the full battery against this commit), publish with--tag dev, and create the lightweightv<devVersion>git tag.Dispatch semantics and the
latestleg are unchanged. OIDC trusted publishing is respected — the dev build is a realnpm publish, not adist-tag add.Invariant delivered: every push to
mainleaves thedevdist-tag pointing at a build of that same commit.Validation
pnpm test:scripts: 169 pass, including 5 newplanPushPublishcases.actionlintonpublish.yml: clean.determine-version.tsfor both push shapes (release bump →version=0.8.0, tag=latest, devVersion=0.8.0-dev.2; routine push →version=0.8.0-dev.2, tag=dev, devVersion=empty).workflow_dispatchfrom this branch: run linked in comments below.Note for the merger
Merging this PR will itself publish a dev build (
0.8.0-dev.N) — that push is the fix's first live proof for the routine-push leg. The release leg proves out at the next release. After the next release merge, verify withnpm view @prisma/composer-cli dist-tags:devmust be on a-dev.Nof the released base.Also closes out two prisma-cli
deferred.mdentries: the dev-tag-parity entry (this PR), and "Composer should drop itsisCIanswer" is stale — composer already dropped it.🤖 Generated with Claude Code