Move the release onto calendar versioning and a prerelease feed - #11
Merged
Conversation
Three real problems, one of which would have shipped a broken update. The release publish steps were gated on `github.event_name == push && startsWith(github.ref, refs/tags/v)`. Switching the trigger to workflow_dispatch without rewriting them would have built, signed, notarised, pushed an appcast entry pointing at a download that does not exist, and published no Release at all. Every installed copy would then fail its update check against a 404. They are gated on !dry-run now. Sparkle cannot be given release candidates. Its comparator tokenises on "." and compares mixed numeric and alphabetic parts, so 26.8.1-rc.1 is not reliably ordered below 26.8.1: an rc in the stable feed can be offered to everyone, and the real release may then not look newer than the rc they already installed. There are two feeds now. appcast.xml carries stable releases only and is what shipped apps read; appcast-prerelease.xml carries everything and is seeded from the current stable history so a tester is never offered a downgrade. A stable release writes both. The concurrency group was per-ref, which does not serialise two different tags, while the job pushes appcast.xml back to main. It is now one group for the repo, and the push rebases rather than failing after the dmg is already built. Versions come from the shared compute-version action, so 0.6.x becomes YY.M.revision. Sparkle reads 26.8.0 as newer than 0.6.0 (26 > 0), so installed copies update correctly across the change. Notes come from the shared changelog action and Discord is announced like every other repo. Signed-off-by: FireBall1725 <fireball@fireball1725.ca>
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.
Phase 2 for LayerLens. Phase 1 (CI and formatting) is already merged; this is the release itself.
I did not build a shared
release-macos.yml. LayerLens is the only macOS-app repo and its release is almost entirely repo-specific — Developer ID signing, notarization, Sparkle EdDSA, appcast — so a reusable workflow with exactly one caller would be speculative. It reuses the shared actions instead:compute-version,changelog, and the Discord announce.Three real problems
1. The publish steps would have silently done nothing. They were gated on
github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v'). Moving the trigger toworkflow_dispatchwithout rewriting them would have built, signed, notarized, pushed an appcast entry pointing at a download that doesn't exist, and published no Release. Every installed copy would then fail its update check against a 404.2. Sparkle cannot be handed release candidates. Its comparator tokenises on
.and compares mixed numeric/alphabetic parts, so26.8.1-rc.1is not reliably ordered below26.8.1. An rc in the stable feed can be offered to everyone, and the real release may then not look newer than the rc they already have. Two feeds now:appcast.xmlappcast-prerelease.xmlSeeded from the current stable history so a tester is never offered a downgrade. A stable release writes both.
3. The concurrency group was per-ref, which doesn't serialise two different tags, while the job pushes
appcast.xmlback tomain. One group for the repo now, and the push rebases instead of failing after the dmg is built.Version scheme
0.6.x→YY.M.revisionvia the shared action. Sparkle reads26.8.0as newer than0.6.0(26 > 0), so installed copies update correctly across the change.Also fixes
.github/release-announce.yml, which Phase 1 merged still carrying the FireBin MCP placeholder text.Not yet run. I'd cut an rc with
dry-run: truefirst, then a real rc, before any stable.