release-rome-image

name	release-rome-image
description	Release a new Rome runtime image by pushing a `vX.Y.Z` tag — pick the version, verify main is releasable, push the tag, and confirm the image published to Docker Hub. Covers the `v*` runtime-image tag only, not the desktop app (`desktop-v*`) and not npm packages (`ui-v*`, `app-runtime-v*`).
disable-model-invocation	true

Release a new Rome image

A pushed vX.Y.Z tag is the release. .github/workflows/docker-publish.yml builds the multi-arch image and publishes it to yunfanye/rome, with no approval gate between the push and Docker Hub. Get explicit confirmation before the push. Verify the published image after it.

The tagging contract covering the semver gate, tag immutability, and latest movement lives in docs/releases.md.

Out of scope

• Desktop releases use the desktop-v* tag and a separate pipeline.
• npm package releases belong to release-please. Never create those tags by hand.

1. Preflight

The tag lands on origin/main, and docker-publish.yml runs no CI gate of its own.

1. Read the commit that the tag will point at.

   git fetch origin --tags && git rev-parse origin/main
   

2. List the recent CI runs.

   gh run list --branch main --workflow CI --limit 5
   

3. Find the run for the exact commit from step 1 and confirm the status is success. CI cancels superseded runs, so a rapid series of merges leaves cancelled runs on real commits. If the run failed, was cancelled, or is still running, stop and report it.

4. Confirm no release is already in flight.

   gh run list --workflow "Docker Hub Publish" --limit 3
   

2. Pick the version

1. Read the current stable tags.

   git tag --list 'v[0-9]*' | sort -V | tail -5
   

2. For a patch release, use the helper in step 3. The helper computes the next patch version.

3. For a minor or major release, take the version from the user.

4. For a prerelease, use vX.Y.Z-rc.N. A prerelease publishes its own docker tag and never moves latest.

Two constraints decide the number. A published version is immutable, so re-pushing a released version fails and the fix for a bad release is the next version up. latest moves only when the new version is the highest stable version in the registry.

3. Cut the tag

For a patch release:

1. Print the planned tag and target commit.

   scripts/dev/create-patch-release-tag.sh --dry-run
   

2. Show that output to the user and wait for an explicit yes.

3. Create and push the tag, which starts the publish.

   scripts/dev/create-patch-release-tag.sh
   

For a minor, major, or prerelease version, the helper does not apply, because it bumps the patch version only. Confirm the version with the user, then tag origin/main directly.

git tag -a v1.1.0 origin/main -m "Release v1.1.0" && git push origin refs/tags/v1.1.0

4. Verify the publish

1. Watch the run to completion.

   gh run watch "$(gh run list --workflow "Docker Hub Publish" --limit 1 --json databaseId --jq '.[0].databaseId')"
   

2. Confirm the version reached the registry.

   curl -fsSL "https://hub.docker.com/v2/repositories/yunfanye/rome/tags?page_size=20" | jq -r '.results[].name'
   

3. Report the published version, whether latest moved, and the build SHA. A running instance reports the baked version at /api/build-info.