fix(version): source displayed version from CARGO_PKG_VERSION #212

Merged
nrupard merged 2 commits from fix/mapps-200-version-source into main 2026-06-16 15:14:42 +02:00
Owner

The footer and System Status page derived the displayed version from git describe --tags (baked as APP_GIT_TAG). That value lags the real release: just create-release bumps Cargo.toml/package.json first, but the vX.Y.Z git tag is only created after the release PR merges, so a build cut right after a 0.3.0 bump still resolved to v0.2.0-N-gHASH and the footer showed "0.2". The OCI build also strips .git (.dockerignore), so git describe cannot run there at all.

Source the displayed version from CARGO_PKG_VERSION (Cargo.toml version, kept in lockstep with package.json), which is correct from the release commit onward and needs no git history in the build context. The commit hash continues to carry exact build provenance. This also makes the footer consistent with the update banner, which already compares against CARGO_PKG_VERSION.

Document the full version-sourcing and staging-vs-production update-target logic in dev-docs/versioning.md and index it in dev-docs/README.md.

#MAPPS-200

Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com

The footer and System Status page derived the displayed version from `git describe --tags` (baked as APP_GIT_TAG). That value lags the real release: `just create-release` bumps Cargo.toml/package.json first, but the `vX.Y.Z` git tag is only created after the release PR merges, so a build cut right after a 0.3.0 bump still resolved to `v0.2.0-N-gHASH` and the footer showed "0.2". The OCI build also strips `.git` (.dockerignore), so `git describe` cannot run there at all. Source the displayed version from `CARGO_PKG_VERSION` (Cargo.toml `version`, kept in lockstep with package.json), which is correct from the release commit onward and needs no git history in the build context. The commit hash continues to carry exact build provenance. This also makes the footer consistent with the update banner, which already compares against `CARGO_PKG_VERSION`. Document the full version-sourcing and staging-vs-production update-target logic in dev-docs/versioning.md and index it in dev-docs/README.md. #MAPPS-200 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fix(version): source displayed version from CARGO_PKG_VERSION
All checks were successful
Check / clippy + fmt + tests (pull_request) Successful in 57s
fb9d9a9b93
The footer and System Status page derived the displayed version from `git describe --tags` (baked as APP_GIT_TAG). That value lags the real release: `just create-release` bumps Cargo.toml/package.json first, but the `vX.Y.Z` git tag is only created after the release PR merges, so a build cut right after a 0.3.0 bump still resolved to `v0.2.0-N-gHASH` and the footer showed "0.2". The OCI build also strips `.git` (.dockerignore), so `git describe` cannot run there at all.

Source the displayed version from `CARGO_PKG_VERSION` (Cargo.toml `version`, kept in lockstep with package.json), which is correct from the release commit onward and needs no git history in the build context. The commit hash continues to carry exact build provenance. This also makes the footer consistent with the update banner, which already compares against `CARGO_PKG_VERSION`.

Document the full version-sourcing and staging-vs-production update-target logic in dev-docs/versioning.md and index it in dev-docs/README.md.

#MAPPS-200

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fix(version): declare CARGO_PKG_VERSION as an explicit build rerun trigger
All checks were successful
Check / clippy + fmt + tests (pull_request) Successful in 59s
Create release / Create release from merged PR (pull_request) Has been skipped
62947a17f8
build.rs emits `rerun-if-changed`/`rerun-if-env-changed` directives, which narrows cargo's build-script reruns to only the declared inputs plus a build-script recompile. The displayed version (APP_GIT_TAG) is read from `CARGO_PKG_VERSION`, but that was only re-baked on a version bump because the `env!("CARGO_PKG_VERSION")` fallback in the same file forces a recompile. That dependency is implicit and fragile: dropping the "redundant" fallback in a future cleanup would stop a version bump from re-running the script, leaving the footer stale (the MAPPS-200 symptom).

Declare `cargo:rerun-if-env-changed=CARGO_PKG_VERSION` so the rerun is guaranteed regardless of the fallback.

#MAPPS-200
nrupard deleted branch fix/mapps-200-version-source 2026-06-16 15:14:42 +02:00
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/mokosh-apps!212
No description provided.