feat: add opt-in canary update channel (desktop + CLI)#3514
Merged
Conversation
A canary build (-X main.channel=canary) polls R2's canary/ pointer instead of latest/, so a stable install can never auto-update onto it. Folded into the existing desktop release workflow as a dispatch-only channel input: build/sign/ manifest are shared, only version/publish/mirror branch on channel. Tag/version/ channel resolution is centralized in scripts/resolve-desktop-release.sh. CLI is unchanged (stays on the npm next tag).
A version containing -canary. publishes to the canary dist-tag instead of next/latest, so npm i reasonix@canary opts in and 1.x (next) / 0.x (latest) users are untouched. release-npm.yml gains a workflow_dispatch canary mode that builds the current ref as <base>-canary.<run_number>.
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.
Adds an opt-in canary channel — desktop and CLI — so testers shake out bugs on a pre-release line before a real release, instead of the stable release doubling as the beta.
Desktop
-X main.channel=canary; the updater then polls R2'scanary/latest.jsonpointer instead oflatest/, so the channels never cross.release-desktop.yml(not a new file): build/sign/manifest are shared jobs; only version/publish/mirror branch on channel. The stabledesktop-v*tag path is unchanged.desktop-canarypre-release, mirrors to R2canary/.mirrormoves only the channel's own pointer — canary writescanary/, stable writeslatest/, an rc moves neither.TestChannelSelectsDistinctPointerspins the URL isolation.CLI
-canary.publishes to a newcanarytag (npm i reasonix@canary); it never movesnextorlatest, so 1.x-on-nextand 0.x-on-latestusers are untouched.release-npm.ymlgains aworkflow_dispatchcanary mode: Actions → Release npm → Run workflow → base_version: 1.5.0 builds the current ref as<base>-canary.<run_number>and publishes it--tag canary. Tag-push (npm-v*) behaviour is unchanged.0.53.1→latest,0.53.1-beta→next,1.5.0→next,1.5.0-rc.1→next,1.5.0-canary.42→canary.Why both
The stable release currently doubles as the beta on both surfaces. CLI was the gap I'd missed first:
nextis the live channel for all 1.x users, not a test buffer, so testers on@nextget production. The separatecanarytag is the actual buffer.Verified
go build/go vet/ desktop unit tests green (incl. channel-isolation test)node --checkon build.mjs; dist-tag routing exercised across all version shapesresolve-desktop-release.shexercised across tag-push / stable-dispatch / canary-dispatch / rc casesNeeds a live run to fully validate
The R2
canary/write + rollingdesktop-canaryrelease, and the npm--tag canarypublish, can only be confirmed by dispatching once each — recommend a test dispatch of both after merge.