fix(client): restore the 2.x screen auto-upgrade path via /client/release.json#492
Merged
Merged
Conversation
…ease.json
2.x screen clients poll /client/release.json to detect new releases. In
3.0 the release file moved to /release.json and the catch-all
/client{subroutes} route answers the old path with the SPA's index.html,
so already-running 2.x screens never detect the 3.0 release and require
a manual reload of every screen.
Ship a copy of release.json at the deprecated public/client/release.json
location in both the production image build and the release tarball.
Static files win over the Symfony catch-all in the nginx image, so 2.x
clients pick up the new release timestamp on their next check and reload
into the 3.0 client. The location is deprecated and only exists to
provide the upgrade path; remove once 2.x clients are out of the field.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
tuj
approved these changes
Jun 10, 2026
…elease-json-upgrade-path # Conflicts: # CHANGELOG.md
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
2 participants
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.
Summary
2.x screen clients poll
/client/release.jsonto detect new releases and reload themselves. In 3.0 the release file moved to/release.json(site root), and the catch-all/client{subroutes}route answers the old path with the SPA's index.html. The 2.x client'sresponse.json()then fails silently, so already-running 2.x screens never detect the 3.0 release — every screen would need a manual reload after the server upgrade.This PR ships a copy of
release.jsonat the deprecatedpublic/client/release.jsonlocation so v2 screens self-upgrade into the 3.0 client on their next release check (every 10 minutes by default). Static files win over the Symfony catch-all in the nginx image, so the copy is served as JSON. The location is deprecated and exists only to provide the upgrade path; remove once 2.x clients are out of the field.Files Changed
infrastructure/display-api-service/Dockerfile- also writepublic/client/release.jsonin the production image build (the nginx image inherits it viaCOPY --from=app).github/workflows/github_build_release.yml- same copy in the release tarballUPGRADE.md- new step 9: auto-upgrade works out of the box for image/tarball deploys; source deploys must generate both files in their deploy process (snippet included)CHANGELOG.md- entry under[Unreleased].gitignore- ignore the new copy alongside/public/release.jsonTest Plan
Verified live on os2display-clone.itkdev.dk (v2 develop → 3.0.0-rc5 upgrade test):
GET /client/release.jsonreturned200 text/html(SPA index); a v2 screen reattached to the API but stayed on the old client indefinitely.GET /client/release.jsonreturns200 application/jsonwith the rc5 timestamp.releaseTimestampon its next 10-minute check and reloaded into the 3.0.0-rc5 client without manual intervention.To verify the build changes: build the production image and check
public/client/release.jsonexists in both the app and nginx images with the same content aspublic/release.json; for the tarball, check the next release archive contains both files.🤖 Generated with Claude Code