Fail the release when Cargo.toml does not match the tag - #77
Merged
Conversation
cargo-wix stamps the MSI ProductVersion from Cargo.toml, while the macOS bundle takes CFBundleShortVersionString from the tag. Nothing held the two together, so a forgotten bump produced a release whose installer Windows would not treat as an upgrade over the previous one. The new job runs before build and is a no-op on workflow_dispatch, where there is no tag to compare against.
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.
Closes #49.
Two things read a version and they disagree. cargo-wix stamps the MSI ProductVersion from Cargo.toml. The macOS bundle takes
CFBundleShortVersionStringfrom the git tag. Nothing checked that they agree, so tagging without bumping Cargo.toml gives a DMG with the right number and an MSI with the old one.The MSI half is the part that lasts. Windows Installer decides upgrades on ProductVersion, so two releases both stamped 0.1.0 mean
MajorUpgradenever fires and the second install does not replace the first. That cannot be repaired after the fact, since the broken installer is already on disk.This adds a
versionjob that build depends on. It compares the tag with the[package]version and fails with the two values in the error if they differ.Behaviour I checked locally against the current manifest at 0.1.0:
main(workflow_dispatch)v0.1.0v0.5.0v1.0.0-rc.1Prerelease tags work because the guard strips only the leading
v, sov1.0.0-rc.1wantsversion = "1.0.0-rc.1", which is valid semver.This does not bump anything. It only stops a release that would ship mismatched artifacts, so the first tag still needs Cargo.toml set to match by hand.