Riyadh
23095c51ea
scripts/update-version.mjs now maintains a `deployCount` integer and
rewrites `version` as `${baseVersion}.${deployCount}` every time the
build hash actually changes. When build is unchanged (re-run without
new commit) it still no-ops, matching prior behaviour, so re-running
the build twice in CI doesn't inflate the counter.
version.json shape:
{
"baseVersion": "0.1.0-dev", <- stable, manually owned
"version": "0.1.0-dev.42", <- baseVersion + "." + deployCount
"build": "20260518.f942f101",
"deployCount": 42
}
Migration: on the very first run after this change, if `baseVersion`
is missing, the script derives it from the existing `version` field
by stripping any trailing `.<digits>`. If `deployCount` is missing it
seeds from that same trailing counter, so a repo that was already
hand-numbered (e.g. "0.1.0-dev.12") doesn't reset progress to 0.
Verified manually:
- Re-run with no new commit -> "build unchanged: ...", file untouched.
- New build -> bumps deployCount by exactly 1, rewrites version.
- Manually editing baseVersion to "0.2.0" -> next bump yields
"0.2.0.<count+1>", manual base preserved.
api-server reads version.json statically (import with type: "json"),
so no API change is needed — the new fields flow through to
/api/system/version automatically. admin.tsx just prints
data.current.version, no regex parsing, so the new suffixed string
shows up in the System Updates card with no UI edit.
version.json reset to baseVersion=0.1.0-dev, version=0.1.0-dev,
deployCount=0 so the next legitimate Mac docker build bumps cleanly
to dev.1 on first redeploy.
7 lines
111 B
JSON
7 lines
111 B
JSON
{
|
|
"baseVersion": "0.1.0-dev",
|
|
"version": "0.1.0-dev",
|
|
"build": "20260517.b5efd9eb",
|
|
"deployCount": 0
|
|
}
|