Releases & Versioning

Overview

We use Changesets to manage versioning and changelogs. Only deployable apps are versioned — utility packages are excluded.

Versioned packages

All other packages (@workspace/ui, @workspace/bridge-core, etc.) are ignored by changesets.

Git flow

feature branch → PR → develop → release/x.y.z → PR → main → tags + version bump

Adding a changeset

When your PR includes a user-facing change to a versioned package, add a changeset:

pnpm changeset

This prompts you to:

1. Select which packages changed (app, editor, web, or docs)
2. Choose a bump type (patch, minor, or major)
3. Write a summary of the change

A markdown file is created in .changeset/ — commit it with your PR.

When to add a changeset

• Yes: new features, bug fixes, breaking changes in app, editor, web, or docs
• No: documentation content-only updates, CI updates, refactors with no user impact, changes to utility packages

Bump types

Release process

1. Merge to main — the Release workflow runs changesets/action, which creates (or updates) a "Version Packages" PR
2. Review the Version PR — it consumes all .changeset/ files, bumps package.json versions, and generates CHANGELOG.md entries
3. Merge the Version PR — git tags are created automatically via privatePackages.tag: true
4. Sync — the sync-develop workflow merges main back into develop

CI pipeline

All PRs to develop and main run:

Commands reference

pnpm changeset              # Add a new changeset
pnpm changeset status       # Check pending changesets
pnpm version-packages       # Apply changesets (CI only)