Cut v1.15.11c — re-tag of v1.15.12 to fix versioning-scheme violation

The 2026-05-28 morning v1.15.12 release violated the project's v{opencode_version}[letter] tagging scheme: opencode-ai stayed at 1.15.11 upstream (no 1.15.12 exists on npm), so the third container build on opencode 1.15.11 should have been v1.15.11c. The commit message of the slipped tag (be2a168) itself said 'OPENCODE_VERSION stays at 1.15.11 (no upstream change)' — the slip was caught the same afternoon during a versioning audit. This release re-cuts at HEAD and supersedes v1.15.12. The slipped git tag and the eight v1.15.12* / latest* Docker Hub images remain as historical artifacts. Future builds on opencode 1.15.11 continue the letter sequence as v1.15.11d, v1.15.11e, etc; v1.15.12 will only be reused if and when opencode upstream actually releases 1.15.12. Includes everything in v1.15.12 plus the afternoon followup work: - CI: registry cache-export disabled (Hub 400 root-cause fix) - Docs: manual host-publish runbook + script archive - CI: workflow-level 3-attempt retry around buildx build --push AGENTS.md: new pre-flight check requirement under Versioning scheme documenting the slip as a cautionary example. Mandatory 'npm view opencode-ai version' check before any non-letter-suffix tag. CHANGELOG: new v1.15.11c block with full content list; v1.15.12 block gets a note documenting the supersession.
2026-05-28 16:54:23 +02:00
parent 1fe5b5df91
commit cb50e6ea60
2 changed files with 34 additions and 0 deletions
@@ -27,6 +27,13 @@ Tags follow `v{opencode_version}[letter]` — e.g. `v1.14.20` for the first buil
 - **No letter suffix** on the first build of a new opencode version — the bare `v{opencode_version}` tag is the canonical release.
 - **Letter suffix is the build ordinal**, starting at `b` for the second build. The letter `a` is **never used** — think of the suffix as counting rebuilds: `b = 2nd, c = 3rd, d = 4th, …`. For opencode version `1.14.20`: first build `v1.14.20`, second `v1.14.20b`, third `v1.14.20c`, and so on.
 - A letter suffix is only used for container-level rebuilds — tooling changes, CVE fixes, doc-driven rebuilds, entrypoint bugfixes — that don't change the underlying opencode version.
+- **Pre-flight check before cutting any non-letter-suffixed tag** — verify the bump is real:
+  ```bash
+  npm view opencode-ai version           # must equal the X.Y.Z in your tag
+  ```
+  If the npm version equals the *previous* release's `X.Y.Z`, you're cutting a letter-suffix rebuild (`vX.Y.Zc`, `vX.Y.Zd`, …), not a new minor. **A bare `vX.Y.Z` tag is a claim that opencode upstream just released `X.Y.Z`** — if that claim is wrong, future opencode releases will collide with your tag namespace and the version-tracking story breaks.
+  
+  Cautionary example: 2026-05-28 morning, `v1.15.12` was cut while opencode-ai was still at `1.15.11`. The commit message itself acknowledged "OPENCODE_VERSION stays at 1.15.11" but tagged `v1.15.12` anyway. Re-cut as `v1.15.11c` the same afternoon (see CHANGELOG). The `v1.15.12` git tag and Hub images stayed as historical artifacts; the slip cost a CI cycle and a CHANGELOG-rewrite. **Run the npm view check at the top of every release-day cut.**

 CI produces eight Docker Hub tags per release: `vX.Y.Z[n]`, `latest`, `vX.Y.Z[n]-omos`, `latest-omos`, `vX.Y.Z[n]-with-pi`, `latest-with-pi`, `vX.Y.Z[n]-omos-with-pi`, `latest-omos-with-pi` — one tag pair (versioned + floating alias) per build variant.