Repository navigation
chore(installer): drop the build number from the installer filename - #24
Merged
Merged
Conversation
The signed installer could not replace the unsigned one, because they were
never named the same thing. The NSI stamped
`DisplayXRMCPSetup-${VERSION}.${BUILD_NUM}.exe`; CI passes the run number while the
signing runner rebuilds with 0, so the two names never collided. `gh release
upload --clobber` had nothing to clobber, and the release would ship a signed
AND an unsigned installer side by side unless /dxr-release remembered to delete
the CI one by name first.
Making the name version-only removes the failure instead of guarding it: the
runner's output collides with CI's, --clobber replaces in place, and there is
no window in which two installers exist. This is already how the browser and
all five demos name theirs, which is why their releases have never needed the
delete step.
BUILD_NUM stays defined; only the filename drops it, and it was never part of
the binary's version resource. Every consumer globs (`DisplayXRMCPSetup-*.exe` in
displayxr-installer's build-bundle.{sh,bat} and the runtime's
setup-displayxr.sh), so the shorter name matches unchanged — verified before
making the change.
No release is recut for this; it takes effect on the next tag.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NLFgqXsgF5ofMgX9BJK7Zv
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.
Problem
The signed installer could never replace the unsigned one, because the two were never named the same thing.
The NSI stamped
<Name>Setup-${VERSION}.${BUILD_NUM}.exe. CI passesgithub.run_number; the signing runner rebuilds with0. So CI producedDisplayXRSetup-2.0.4.1883.exeand the runner producedDisplayXRSetup-2.0.4.0.exe—gh release upload --clobberhad nothing to clobber, and the release would ship a signed and an unsigned installer side by side unless the release skill remembered to delete the CI asset by name first.That's a silent, expensive failure guarded by a step that has to remember to fire.
Fix
Make the name version-only. The runner's output then collides with CI's,
--clobberreplaces it in place, and there is no window in which two installers exist — the failure is removed rather than guarded.This is already how the browser and all five demos name theirs. It's why their releases have never needed the delete step, and why the three demo releases cut today each landed exactly one
.exewithout it firing.Safety
BUILD_NUMstays defined and still flows to the inner build. Only the filename drops it. It was never inVIProductVersion, so nothing about the binary's version resource changes.<Name>Setup-*.exeindisplayxr-installer'sbuild-bundle.{sh,bat}, the runtime'ssetup-displayxr.sh, and bothsoftpropsupload steps. Verified across both repos before making the change; the shorter name matches unchanged.Docs
Both release skills described the delete as "load-bearing". It is now a safety net against a regression rather than the normal path, and the distinction matters: a reader who believes the delete is what guarantees a single asset will trust it instead of the asset-count assertion, which is the check that actually catches this. Updated both, plus the workflow comments that quoted the old four-part name.
No release is recut for this — it takes effect on the next tag.
🤖 Generated with Claude Code
https://claude.ai/code/session_01NLFgqXsgF5ofMgX9BJK7Zv