Release prep 1.0.0: version bump, appcast cleanup, stable-release tagging

[malpern]

Prepares master for the 1.0.0 stable cut. Landing this first means release.sh can run with no version arg, so its in-place CFBundleVersion=<full-string> auto-bump (which Sparkle would mis-compare as older than beta3) never runs, and the v1.0.0 tag captures a tree that already says 1.0.0.

Changes

• Info.plist — CFBundleShortVersionString 1.0.0-beta3 → 1.0.0; CFBundleVersion 3 → 4. build-and-sign.sh writes <sparkle:version> from CFBundleVersion, so 4 > 3 is what makes existing beta3 users get offered the update.
• appcast.xml — remove the stale Version 1.0.0 entry (sparkle:version=1, enclosure pointing at a non-existent v1.0.0 release) left over from a prior local run. With 1 < 3 it was a permanently-unofferable broken entry; leaving it would put a bogus 1.0.0 next to the real one.
• release.sh — mark the GitHub Release --prerelease only for versions with a semver pre-release suffix (e.g. 1.0.0-beta4); stable X.Y.Z now publishes as Latest release. Scalar + ${x:+...} form keeps it safe under set -u on bash 3.2 (macOS).
• CHANGELOG.md — cut [1.0.0] section from [Unreleased] (security: cmd-feature removal; feature list; known limitations).

Deliberately NOT changed

• Sources/KeyPathHelper/Info.plist stays at 1.1.0/2. It already drifted from the app before this release; bumping it changes the bundled privileged helper and can trigger a re-approval prompt for existing users on auto-update. Reconciling helper versioning is a clean post-1.0 follow-up.

Verification

• plutil -lint Info.plist ✓
• xmllint --noout appcast.xml ✓ (well-formed; only beta3 + the to-be-appended 1.0.0 entry remain)
• bash -n release.sh ✓ and prerelease logic unit-checked: 1.0.0 → Latest, 1.0.0-beta4 → --prerelease
• No Swift changes (release-config only), so the Swift review gate is N/A.

Also done out-of-band on this clone

• Deleted 6 stale local-only tags (v1.0.0–v1.0.4, v1.0.4-2) — 2022-era inherited Kanata tags never pushed to KeyPath's origin — so release.sh can create v1.0.0. SHAs recorded; commits stay reachable.

After merge: pull master → release-candidate.sh (signed/notarized QA in /Applications) → smoke → release.sh 1.0.0.

[claude]

Review: Release prep 1.0.0

Overall this is a tight, well-scoped release-prep PR. The rationale is clearly documented and the changes are minimal. A few notes below.

---

✅ What's correct

Info.plist version bumps — CFBundleShortVersionString 1.0.0-beta3 → 1.0.0 and CFBundleVersion 3 → 4 are both correct. Sparkle compares CFBundleVersion (the integer build number) when deciding whether to offer an update, so 4 > 3 ensures existing beta3 users are prompted. Storing it as <string> in the plist is standard.

appcast.xml cleanup — The removed entry had sparkle:version=1, so 1 < 3 (beta3's build number) and it was permanently un-offerable. The enclosure URL pointed at a non-existent release asset. Removing it is correct; leaving it alongside the real 1.0.0 entry would have created a confusing duplicate with a broken download URL.

Pre-release detection logic — [[ "$VERSION" == *-* ]] correctly identifies semver pre-release strings (anything with a hyphen). Stable X.Y.Z versions fall through cleanly.

set -u safety — Explicitly initializing PRERELEASE_FLAG="" before the conditional covers the case where the script runs with set -u. The ${PRERELEASE_FLAG:+...} form then safely handles the empty-string case without passing a blank argument to gh.

CHANGELOG — Cutting the 1.0.0 section from Unreleased looks correct. Dropping the internal CI notes ("CI enforces coverage non-regression…") and the release-blocker issue reference is appropriate for a user-facing changelog. The Security section leading the 1.0.0 entry is a good call given the cmd feature removal is a meaningful safety property.

---

Minor findings

release.sh: slight redundancy in the flag expansion

PRERELEASE_FLAG=""
if [[ "$VERSION" == *-* ]]; then
    PRERELEASE_FLAG="--prerelease"
fi
...
${PRERELEASE_FLAG:+"$PRERELEASE_FLAG"} \

Because the flag string is a constant (--prerelease), the variable reference in the expansion is redundant — the value of PRERELEASE_FLAG is already identical to the string you'd want to substitute. A slightly cleaner form is:

${PRERELEASE_FLAG:+--prerelease} \

No functional difference; just removes one indirection. Not a blocker.

--notes URL is self-referential

--notes "See [release notes](https://github.com/malpern/KeyPath/releases/tag/v${VERSION}) for details."

The body of the GitHub Release links back to the same release page. This is pre-existing behavior (not introduced here), but worth fixing at some point — e.g., linking to the CHANGELOG or a help guide instead.

CHANGELOG missing comparison links

Keep a Changelog convention expects a footer link block like:

[1.0.0]: https://github.com/malpern/KeyPath/compare/v0.0.0-internal...v1.0.0
[0.0.0-internal]: https://github.com/malpern/KeyPath/commits/v0.0.0-internal

These are optional if the repo doesn't use them today, but worth adding at some point for navigability. Not blocking for 1.0.0.

[Unreleased] section — After this PR, the [Unreleased] section is empty. That's correct per Keep a Changelog conventions (empty is the right state between releases), just confirming it's intentional.

---

No concerns on

• Helper plist staying at 1.1.0/2 — the reasoning (avoid re-approval prompt on auto-update) is sound, and it's explicitly noted in the PR description.
• No Swift source changes means the Swift review gate and test suite are not relevant here.
• The VERSION == *-* check won't false-positive on realistic version strings in this project.

---

Verdict: Ready to merge. The minor notes above are all post-1.0 cleanup candidates, nothing blocking.