chore(installer): stamp the real release version into installer artifacts - #3105
Merged
Conversation
The installer artifact shipped in v0.18.1 reported 1.0.0 because the mac Info.plist hardcoded it and nothing else carried a version at all, so a user or support engineer could not tell which build they had. - resolve one version from the release tag (local builds fall back to apps/installer/package.json) and stamp it into the compiled binary, the mac Info.plist, the DMG volume name, and the Windows version resource - add `--version` to the installer CLI and a quiet footer in the window - keep apps/installer/package.json on the release train via bump-version Published asset filenames are unchanged.
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
1 participant
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.
The installer shipped as an unversioned artifact:
apps/installer/package.jsonwas pinned at0.1.0, the macOS bundle hardcodedCFBundleShortVersionString1.0.0, the Windows.execarried no version resource, and nothing in the UI or on the binary told you which build you had. That makes support ("which installer are you running?") guesswork.What changed
apps/installer/scripts/installer-version.mjs. Precedence is explicit flag/env, then the release tag, then the committedpackage.json— so a developer build never claims to be a release.bun build --definefor the runtime constant, the signed macOSInfo.plist(bothCFBundleShortVersionStringandCFBundleVersion), a Windows version resource plus title/publisher/description on the.exe, and the DMG volume name.--versionand the build fails if it does not reportopenwork-installer <version>, so a silently unstamped artifact cannot ship.bump-version.mjsnow bumpsapps/installer/package.jsonalongside the other packages and includes it in the release commit, so the fallback stays truthful.Asset filenames are deliberately unchanged
The published names stay
OpenWork-Installer-mac-arm64.dmg/-mac-x64.dmg/-win-x64.exe. den-api'sgenericInstallerArtifactName()resolves download links by those stable names, and the org install guide in den-web now shows the exact filename to the user, so putting a version in the filename would break both. The version lives inside the artifact instead, where it is signed and inspectable.Testing
bun testinapps/installer— 52 pass, 0 fail--release-tag v0.19.0→0.19.0, with--windows→0.19.0.0, and no tag →0.18.1frompackage.jsonNot verified locally: the macOS signing/notarization and Windows resource-stamping paths only run in CI with release credentials, so the end-to-end stamp needs a release build to confirm. The
--versionassertion in the workflow is what guards it.Made with Cursor