version missing from top right dropdown #483

New Issue

2026-11-06T09:33:37Z

allan commented

2026-11-06 09:33:37 +00:00

![image.png](attachments/5b9cf21c-ba4f-4793-b8a7-5595ca2e973f)

image.png

10 KiB

hermes referenced a pull request that will close this issue

2026-11-06 09:46:39 +00:00

fix(version): fall back to package.json when no tag is reachable #484

hermes commented

2026-11-06 09:46:43 +00:00

Diagnosed and fixed in #484.

The footer renders VERSION.tag + '.' + VERSION.hash. client/src/version.ts gets that from git-describe, which only sees tags reachable from HEAD; CI checks out a single commit, so there is no reachable tag, tag comes back null, and the stamp is just the hash prefixed with v. The release job's final frontend build runs in that same shallow checkout, so shipped builds carry the hash-only stamp.

The fix falls back to the root package.json version when git-describe finds no tag (semantic-release bumps it before the shipped build), so the dropdown reads the semantic release plus the commit hash again. A new spec pins the generated stamp and fails against the old generator.

Diagnosed and fixed in #484. The footer renders `VERSION.tag + '.' + VERSION.hash`. `client/src/version.ts` gets that from `git-describe`, which only sees tags reachable from HEAD; CI checks out a single commit, so there is no reachable tag, `tag` comes back `null`, and the stamp is just the hash prefixed with `v`. The release job's final frontend build runs in that same shallow checkout, so shipped builds carry the hash-only stamp. The fix falls back to the root `package.json` version when git-describe finds no tag (semantic-release bumps it before the shipped build), so the dropdown reads the semantic release plus the commit hash again. A new spec pins the generated stamp and fails against the old generator.

allan closed this issue

2026-11-06 10:19:19 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dc/dc#483