fix: bump every version reference to 2.23.2, and guard it in CI - #139
Merged
Conversation
v2.23.1 bumped only the frontend manifests and the three doc stamps. Six
references were missed, and two of them were not cosmetic:
backend/__init__.py the UI reads its version from here, via
useVersion.ts -> GET /health -> server.py
-> backend.__version__, so the running app
kept reporting 2.23.0
docker-compose.images.yml still pinned to the v2.23.0 images, so
docker-compose.portainer.yml deploying from these files or running
prereq.sh prereq.sh silently installed the previous
release
Bump all nine references across the six files, plus the README, USER_MANUAL
and docs/index.html stamps.
USER_MANUAL.md:443 ("Since v2.23.1 Hearthwave stores the device ...") is left
alone -- that names the release the feature actually landed in.
The skill covered README, USER_MANUAL and docs/index.html, and treated frontend/package.json as the source of truth for the new version number -- but it never said where else that number has to be written. That gap is why v2.23.1 shipped reporting 2.23.0. Add Step 1b: a table of all nine references across six files, why each one matters, and a verification grep that must come back empty. Note the two intentional exceptions (historical prose, CHANGELOG entries) so they are not rewritten by mistake, and instruct the next person to add a row if the grep surfaces a file the table does not list. Also widen the frontmatter description -- calling this a docs-updating skill is part of why the code and deploy files were skipped.
A checklist only works if someone reads it. Add scripts/check_version_sync.py,
which asserts that all nine version references agree with the version in
frontend/package.json, and wire it into CI:
- version-sync.yml runs on every PR and on pushes to master, so a partial
bump fails before a tag exists
- docker-publish.yml gains a version-sync job that build-backend and
build-frontend now depend on, so a mismatched tag cannot publish
The script also rejects a version tag that disagrees with the tree, which would
otherwise publish images that misreport themselves.
Deliberately a consistency check rather than a grep for the previous version:
the docs legitimately name past releases ("Since v2.23.1 Hearthwave stores the
device ..."), so scanning for stale strings would fail on prose that is correct.
Verified it catches the actual v2.23.1 regression -- reverting
backend/__init__.py and prereq.sh to 2.23.0 makes it exit 1 naming both files.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
v2.23.1 shipped reporting itself as v2.23.0. The release bumped the frontend manifests and the three doc stamps, but missed six references — two of them not cosmetic:
backend/__init__.py— the UI reads its version from here (useVersion.ts→GET /health→server.py→backend.__version__), so the running app displayed the previous version. This is what a user noticed.docker-compose.images.yml,docker-compose.portainer.yml,prereq.sh— still pinned to thev2.23.0images, so deploying from those files or runningprereq.shsilently installed the previous release.Re-tagging v2.23.1 isn't an option: those images are already published to GHCR, so moving the tag would leave two different builds under one version. Hence a patch.
What
36e44de— bump all nine references across six filesbackend/__init__.pyfrontend/package.jsonfrontend/package-lock.jsondocker-compose.images.ymldocker-compose.portainer.ymlprereq.shPlus the doc stamps in
README.md,USER_MANUAL.md,docs/index.html.USER_MANUAL.md:443(Since v2.23.1 Hearthwave stores the device ...) is deliberately left alone — it names the release that feature actually landed in.ca032ae— close the gap in the release skill.superpowers/skills/release.mdcovered README, USER_MANUAL anddocs/index.html, and treatedfrontend/package.jsonas the source of truth for the version number — but never said where else that number has to be written. New Step 1b lists every location and why each matters.46a832a— enforce it, because a checklist only works if someone reads itscripts/check_version_sync.pyasserts every location agrees withfrontend/package.json, and also rejects a version tag that disagrees with the tree. Wired in twice:version-sync.ymlon every PR and push to master — fails before a tag existsversion-syncjob indocker-publish.ymlthat both build jobs nowneeds:— a mismatched tag cannot publishIt's a consistency check, not a grep for the old version string: the docs legitimately name past releases, so scanning for stale strings would fail on prose that's correct.
Verification
backend/__init__.pyandprereq.shto2.23.0makes it exit 1 naming both files, i.e. it catches the actual regressionGITHUB_REF=refs/tags/v2.23.1→ exit 1;v2.23.2→ passneeds:wiring confirmed🤖 Generated with Claude Code