Release lines and upgrades
The lines
| Branch | Major | Release tags | Runner image tags |
|---|---|---|---|
main | 5.x | v5.y.z | sha-<commit>, 5.x |
4.x | 4.x, maintained | v4.y.z | sha-<commit>, 4.x, main |
next | the next major, when one is being built | vN.0.0-rc.M | sha-<commit>, next |
Every release is a git tag on its line plus a GitHub release with notes, cut automatically on green CI. There is no npm package: an installation pins a commit, and the tag says which commits are releases. 4.x was cut from main at the last commit before 5.0.
Pin a release
- A vocion-core submodule:
git -C vocion-core fetch --tags && git -C vocion-core checkout v5.y.z, then commit the submodule. - vocion-stack:
core_ref = "v5.y.z"(a branch is rejected). - The runner image:
VOCION_RUNNER_IMAGE=ghcr.io/vocion/vocion-runner:sha-<that commit>. Whatever moves the app pin moves the runner pin in the same commit.
Upgrade
- Read the release notes between your tag and the new one.
- Move the pin (app and runner).
- Deploy. Migrations run before the new app starts; on vocion-stack the deploy does it, elsewhere run
npm run db:migrateorinfra/aws/apply-migrations.sh. - Re-apply workspaces if the base pack or plugins you use changed:
npm run workspace:apply -- <path> --project <slug>.
Roll back
Deploy the previous tag. Migrations only move forward and are written expand-then-contract, so the previous release runs on the newer schema. The 5.0 migrations are additive: returning to a 4.x pin works without a restore.
Bump automation
A bot follows what it is pointed at. Prefer a release over a branch head:
latest— the newest release on any line (the current major)latest-4— the newest 4.x release- a branch (
main,4.x,next) — every commit that lands, released or not
A bot that follows main moves a 4.x installation to 5.x on its next run. To stay on 4.x, see Migrating to 5.0.