Skip to content

RELEASING.md

Latest commit

 

History

History
21 lines (12 loc) · 1.53 KB

RELEASING.md

File metadata and controls

21 lines (12 loc) · 1.53 KB
Raw

Releasing

Stable release

Every push to master cuts the next patch release automatically (except pushes that only touch markdown, .github/, or .claude/ files). Each release:

  1. Computes the next vX.Y.Z tag and publishes a GitHub release from the pushed commit.
  2. Builds the frontend and attaches lab-<tag>.tar.gz / lab-<tag>.zip to the release.
  3. Dispatches a frontend-release event to lab-backend, which tags its own next release and builds Docker images embedding this exact frontend version.

End to end this takes ~10 minutes; the lab-backend release notes and /lab-backend/version output record which frontend tag was embedded.

Include [skip release] in the commit message (or squash-merge PR title) to opt a push out.

For a minor/major bump, run the Release workflow manually (or gh workflow run release.yaml -f bump=minor). Publishing a release by hand through the GitHub UI also works — the release publish event runs the same workflow from step 2 onwards.

Deploying the resulting image is still a manual bump of image.tag in the platform lab application values.

Alpha releases

Pushing to a release/<name> branch auto-tags and publishes a prerelease named <name>-vX.Y.Z with the same archives attached. Prereleases do not trigger a lab-backend release; to build a backend image against one, run the lab-backend release workflow manually with frontend_tag: <name>-vX.Y.Z.