All package publishing happens in GitHub Actions. Do not publish from your local machine.
- If your PR changes a publishable package, run
pnpm changesetand commit the generated.changeset/*.mdfile. - Merge the PR into
main. - For a stable release:
- Run Prepare Release on
main. - Review the generated prepare release PR.
- Run Publish Stable Release with the
release_shashown in the prepare workflow summary. - Approve the
npm-publishenvironment. - The publish workflow publishes from the exact commit SHA, creates tags and GitHub Releases for that commit, and comments on issues closed by released PRs.
- Merge the prepare release PR after publishing succeeds.
- Run Prepare Release on
- For a prerelease from a branch:
- Run Publish Prerelease Snapshot with
ref=<branch, tag, or SHA>. - Install from the
rctag, for examplenpm install braintrust@rc.
- Run Publish Prerelease Snapshot with
If your PR changes a publishable package, CI expects a changeset unless you explicitly skip it.
Create one with:
pnpm changesetThat creates a .changeset/*.md file. Commit it with your PR.
Use:
patchfor fixes and non-breaking maintenance changesminorfor new backwards-compatible featuresmajorfor breaking changes
If no release is intended, bypass the check with either:
- the
skip-changesetPR label #skip-changesetin the PR title or body
This is the normal production release flow.
- Merge feature PRs into
main. - Run Prepare Release from
main. - That workflow:
- validates publishable package metadata
- runs
changeset version - creates a branch named
prepare-release/{short-main-sha} - opens a prepare release PR from that branch into
main - writes the
release_shato the workflow summary
- Review the prepare release PR to confirm the package versions, changelogs, and consumed changeset deletions look right.
- Run Publish Stable Release with:
release_sha=<full commit SHA to publish>
- Approve the
npm-publishenvironment when GitHub asks. - Merge the prepare release PR after publishing succeeds.
The stable publish workflow checks out release_sha exactly. It accepts any full commit SHA with a parent, does not resolve the prepare release PR, and does not publish from the current tip of main.
The workflow then:
- detects packages whose versions changed between the release commit and its first parent
- publishes any of those package versions that are not already on npm
- pushes Changesets-style release tags for the release commit
- creates GitHub Releases
- comments on issues closed by PRs included in the release
If publishing succeeds but the prepare release PR cannot be merged cleanly afterward, the release is still published. Repair or recreate the prepare release PR manually afterward.
Stable releases publish to the npm latest dist-tag.
Use this to publish a test build from a branch before merging to main.
- Run Publish Prerelease Snapshot.
- Set:
ref=<branch, tag, or SHA>
- Wait for the workflow to finish.
- Install from
rc, for example:
npm install braintrust@rcPrereleases:
- publish only packages with releasable changesets on that ref
- publish to the npm
rcdist-tag - do not create git tags
- do not create GitHub Releases
- do not commit version changes back to the repo
- Prepare Release must be run from
main. - Stable publishing must use a full 40-character commit SHA, not a PR number. In the normal prepare release flow, use the
release_shafrom the Prepare Release summary. - The old
releasebranch and backsync workflow are no longer part of the release process. - Re-running Publish Stable Release for the same
release_shais safe after a partial failure. Already-published npm versions are skipped, but tags and GitHub Releases are still reconciled for the prepared release set.