Skip to content

fix: SwiftBuddy app version permanently stuck at 1.0 (build 1) - #162

Open
solderzzc wants to merge 1 commit into
mainfrom
fix/app-version-numbering
Open

fix: SwiftBuddy app version permanently stuck at 1.0 (build 1)#162
solderzzc wants to merge 1 commit into
mainfrom
fix/app-version-numbering

Conversation

@solderzzc

Copy link
Copy Markdown
Member

Summary

The app's displayed version never changed across any release, ever. Root cause: SwiftBuddy/generate_xcodeproj.py regenerates project.pbxproj fresh on every build (it's gitignored, not a checked-in file), and MARKETING_VERSION/CURRENT_PROJECT_VERSION were hardcoded literals baked into its template. Neither release.yml (which releases roughly daily, tagged bNNN by commit count) nor build-dmg.yml ever touched them, so every DMG and app bundle ever built — regardless of which commit or release tag it came from — reported itself as "SwiftBuddy 1.0" build "1". scripts/build_dmg.sh already reads CFBundleShortVersionString from the built app for the DMG filename, so this silently named every DMG SwiftBuddy-macOS-v1.0.dmg too.

Fix

  • generate_xcodeproj.py now reads both values from env vars (SWIFTBUDDY_MARKETING_VERSION, SWIFTBUDDY_BUILD_NUMBER), defaulting to the previous hardcoded values when unset — local/manual python3 generate_xcodeproj.py runs are unaffected.
  • release.yml and build-dmg.yml now set:
    • build number = git rev-list --count HEAD, the same counter release.yml already uses for its bNNN release tags, so the app's build number and its release tag always agree.
    • marketing version = build date (YYYY.MM.DD) — always distinct per day, no manual "when do we bump this" decision needed for a pipeline that releases close to daily.
  • build-dmg.yml's checkout gained fetch-depth: 0 — it was a shallow clone, so git rev-list --count HEAD there would've returned ~1 regardless of actual history (release.yml already had this for the same reason).

Verification

Ran python3 generate_xcodeproj.py locally:

  • With no env vars set: reproduces the exact previous hardcoded output (MARKETING_VERSION = 1.0, CURRENT_PROJECT_VERSION = 1) — confirms no behavior change for local/manual runs.
  • With SWIFTBUDDY_MARKETING_VERSION=2026.08.27 SWIFTBUDDY_BUILD_NUMBER=703: both values interpolate correctly into the generated project.pbxproj.
    Both workflow YAML files validated with yaml.safe_load.

Test plan

  • Local dry-run of generate_xcodeproj.py with and without env vars.
  • CI green (this touches release infra — the actual release.yml run is the real end-to-end check).

generate_xcodeproj.py regenerates project.pbxproj fresh on every build
(it's gitignored, not a checked-in file), and MARKETING_VERSION/
CURRENT_PROJECT_VERSION were hardcoded literals in its template. Neither
release.yml (which releases roughly daily, tagged bNNN by commit count)
nor build-dmg.yml ever touched them, so every DMG and app bundle ever
built — regardless of commit or release tag — reported itself as
"SwiftBuddy 1.0" build "1". scripts/build_dmg.sh already reads the real
CFBundleShortVersionString out of the built app for the DMG filename, so
this was silently naming every DMG SwiftBuddy-macOS-v1.0.dmg too.

Makes both values overridable via env var (SWIFTBUDDY_MARKETING_VERSION,
SWIFTBUDDY_BUILD_NUMBER), defaulting to the previous hardcoded values
when unset so local/manual `python3 generate_xcodeproj.py` runs are
unaffected.

release.yml and build-dmg.yml now set:
- build number = `git rev-list --count HEAD`, the same counter release.yml
  already uses for its bNNN release tags, so the app's build number and
  its release tag always agree.
- marketing version = build date (YYYY.MM.DD) — always distinct per day,
  no manual "when do we bump this" decision needed for a pipeline that
  releases on close to a daily cadence.

build-dmg.yml's checkout also gained fetch-depth: 0 — needed for
`git rev-list --count HEAD` to see full history (it was a shallow clone;
release.yml already had this for the same reason).

Verified locally: `python3 generate_xcodeproj.py` with no env vars set
reproduces the exact previous hardcoded output (1.0/1); with
SWIFTBUDDY_MARKETING_VERSION/SWIFTBUDDY_BUILD_NUMBER set, both interpolate
correctly into the generated project.pbxproj.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant