Versioning and releases

Changesets records user-visible changes and drives release pull requests. The six deployable apps form one fixed version group:

{
  "fixed": [[
    "@vigor/web",
    "@vigor/platform",
    "@vigor/partner",
    "@vigor/api",
    "@vigor/docs",
    "@vigor/marketing"
  ]]
}

Fixed means a release that bumps one member aligns all six app versions. It does not mean every shared package has the same version; package dependency updates still follow the Changesets configuration.

Record a change

bun changeset

Select the affected workspace, choose the semantic bump, and write a consumer-facing summary. Commit the generated file with the implementation. Internal refactors that have no observable release effect do not need invented release notes.

Version and publish

On main, .github/workflows/release.yml uses the Changesets action. Pending changesets update or create the release pull request. Merging that pull request applies versions and changelogs; the next release run publishes or tags according to package settings.

The root commands are:

bun run version
bun run release

bun run version runs changeset version and refreshes the Bun lockfile metadata. The publish command builds publishable packages before changeset publish. CI uses Bun 1.4 and runs install, database migration, lint, typecheck, tests, and the workspace build before a change is treated as healthy.

Scope changes

The default fixed group always contains exactly the six apps above. If the signed scope removes an optional app, change this group only as part of the same approved scope change and update the deployment plan. Never remove an app from the release group only to avoid a failing build or version bump.

Before releasing, confirm the changeset describes the delivered behavior, the fixed group is intact, migrations are deployable, and optional client notifications follow the signed communication plan.