Repository navigation
Release gate: verified in-app updates on macOS, Windows, and every supported Linux install shape #73
Description
Product decision (2026-10-21)
Self-update is a cross-platform requirement, not a macOS-only milestone. Shipping a new stable release solely because a macOS update PR passes misses this product requirement.
Current status, checked against main and the Rivet v0.12.0 pin
| Installed app | Signed discovery/download | Install and relaunch | Readiness |
|---|---|---|---|
| macOS Apple Silicon + Intel (.app installed in Applications) | Backend available; PR #65 proposes CryptoKit native verification with rollout/minimum-version/channel parity | Native zip swap proposed in #65 | Unproven: signed real old→new upgrade, abort, rollback, wrong-key/corrupt archive and install location; no merge until proven |
| Windows x64 MSI | Backend verifies Ed25519 feed + size/SHA256; official host calls rivet::update::MsiHandoff |
msiexec /passive /norestart, quit and relaunch, failure marker exists |
Code present; still require actual installed old→new MSI upgrade / failure / retry tests on Windows runner |
| Linux AppImage x64 + arm64 | Backend selects signed AppImage artifact in AppImage runtime, downloads, size/SHA verifies (#29) | Missing in Fulcrum: no install action or atomic replace/relaunch in GTK host | Release blocker: #30 reopened. Rivet upstream #291 contains AppImageHandoff on main, but pinned v0.12.0 predates it. Adopt verified immutable Rivet revision, wire external handoff with signed version/digest + instance release, then test interrupted transaction recovery/rollback |
| Linux installed .deb / .rpm | Signed feed and artifacts are available | Must use OS package-manager transactions, not destructive writes to /opt or /usr | Show Update through package manager with actionable non-root guidance; never falsely offer direct replacement. Clarify whether repo-based unattended update is supported |
| Linux portable tar.gz | Backend verifies and downloads tar.gz | Manual extraction guidance only | Either implement an explicitly supported, crash-safe portable installation update, or label portable mode as manual (and do not claim universal one-click self-update until addressed) |
Minimum release acceptance for each supported auto-updating installation
- On an installed
vN, Check for Updates discovers a signedvN+1of the same application, stable channel, architecture, installer kind, obeyingminimum_versionand stickyrollout. - Download follows CDN redirects but enforces signed size, SHA-256, timeout and cancellation; corrupted/mismatched signatures, wrong key/app ID/architecture, unsupported installer and oversize payload fail closed.
- Install in app performs a native safe handoff (macOS .app zip swap; Windows MSI; Linux AppImage external transaction), releasing resident-instance ownership and launching the new version automatically. Never overwrite a package-managed app directly.
- Failure paths: installer failure, interrupted swap, download cancellation, blocked permissions, no disk space; preserve or restore the previous working install, show a recoverable error and never corrupt user settings.
- E2E: real installed version N→N+1 for macOS arm64/x64, Windows x64, AppImage x64/arm64; confirm the new version on next launch and a reliable retry. Local unit/mock tests are insufficient.
- Release
vN+1contains every architecture's installed payload and a cross-platform Ed25519 signed update manifest whose asset URLs/architecture/installer match actual release assets. Feed consumers must see it only after all release jobs and verification complete. - The release notes distinguish development/ad-hoc signing from genuine Apple Developer ID notarization (release(macos): Developer ID signing and notarization for normal Gatekeeper first launch #72); do not advise disabling Gatekeeper.
Dependencies and acceptance scope
- Mac updater fix(macos): switch updates to RivetUpdate CryptoKit verifier and installer #65 (Draft) and DMG install feat(macos): Taskly-style drag-to-Applications DMG and first-launch guide #71.
- Linux AppImage last mile Linux updater: complete AppImage atomic install + relaunch #30 and Rivet upstream #291; the upstream work is merged but not present in the pinned v0.12.0 release.
- Windows MSI last-mile is implemented on main, but installed-version upgrade/rollback/failure E2E is not yet evidenced.
- Patch release (candidate v0.13.3) must be gated on this matrix, not merely the ordinary CI and Product Acceptance green badges.
This issue is the cross-platform feature/release gate. Do not close when only one platform is fixed.
Activity
turinglambdaai commentedon Oct 21, 2026
Cross-platform update gate progress: Linux AppImage implementation is now in Draft #75, replacing #74. It includes Rivet's external atomic handoff, backend signed SHA/version metadata, GTK exit/relaunch, failed-update recovery and test fixtures; real x64/arm64 installed-AppImage upgrade tests remain. Mac branded DMG #71 exposed a genuine codesign failure caused by dereferenced Racket.framework symlinks in upstream Rivet's branded-DMG copy; Rivet #300 now fixes staging via
dittowith a mounted-DMG symlink regression test, and #71 is testing that fix against an immutable provisional Rivet SHA. Mac updater #65 is CI/acceptance green but Draft pending actual signed install/rollback. Windows MSI E2E still required. No version bump or release until all gates pass.turinglambdaai commentedon Oct 21, 2026
2026-10-21 current progress: AppImage Draft #75 has a passing Linux official-build + headless Rivet success/rollback transaction on an earlier commit; latest head
c1724138includes additional package-manager ownership hardening: never show a tarball download/replace action for a DEB/RPM-installed app under/optor/usr, refuse direct install/download row misuse, display apt/dnf or proper DEB/RPM guidance. Latest-head CI and Product Acceptance are queued. A prior Ubuntu backend job failed to fetch the Racket installer with a TLS disconnect (workflow still running, so GitHub 403 prevented rerun); no code defect was shown there. Mac drag-install PR #71's latest CI has passed Linux/Windows build plus Linux/Windows packaged acceptance, but macOS tests remain queued; upstream Rivet #300 repairs signature-breaking symlink dereference in branded DMG staging and must pass its own CI before merge/pinning. Mac updater Draft #65 has automated CI + Product Acceptance green but needs actual signed installed-app upgrade/rollback. Windows MSI installed old→new & failure recovery E2E remains unproven. No full-platform release clearance or new tag yet.turinglambdaai commentedon Oct 21, 2026
Additional Windows release-gate coverage now under Draft PR #76: a dedicated Windows runner downloads v0.13.1 and v0.13.2 official MSI assets, verifies each published SHA-256, installs the older package via
msiexec /qn, checks the registered version and installed executable, applies the newer MSI major upgrade, and verifies there is exactly one correct installed version. The workflow is actually running (not just static source assertions). This validates MSI upgrade packaging, not yet the installed-app MsiHandoff/Ed25519 GUI interaction or failure recovery; keep those #73 requirements open until a signed-feed/in-app old→new E2E and failure-retry check is demonstrated. macOS branded DMG PR #71 now has both latest-head CI and Product Acceptance green and strict mounted DMG signature verification passed; upstream Rivet #300 still has unfinished checks and is not merged, so release remains blocked. Linux AppImage #75 remains Draft awaiting latest CI and actual upgrade E2E.turinglambdaai commentedon Oct 21, 2026
2026-10-22 Windows validation update: Draft PR #76 ran on the real Windows 2025 GitHub runner. After correcting its strict-mode registry filter, its first successful run downloaded official MSI releases v0.13.1 and v0.13.2, verified both publisher-provided SHA-256 checksums, installed the previous release, and completed the real on-disk MSI major upgrade with a single current-version registration and installed executable. A follow-up test now also attempts to install the older MSI over the new release, and asserts that the downgrade is refused while the new installation remains valid; latest-head CI is queued. This is stronger evidence for Windows MSI packaging, but still not proof of app-triggered signed-manifest MsiHandoff, quit/relaunch, or failure retries. Keep #73 open until that additional workflow and macOS/Linux real upgrade matrices pass. macOS #71 CI and Product Acceptance have both completed successfully, including strict mounted-DMG codesign; its upstream Rivet #300 still has queued mandatory checks, so no unsafe dependency merge or version tag.
turinglambdaai commentedon Oct 22, 2026
2026-10-22 continuation: PR #76 is now merged at
033f986120a7ad58eb98ba8a429022f36fc28192. Its Windows 2025 runner verified SHA-256 sidecars for official v0.13.1/v0.13.2 MSI assets, installed v0.13.1, upgraded to v0.13.2 with one correct registration and executable, rejected installing v0.13.1 over v0.13.2, and cleaned up successfully.Added a real-release AppImage handoff E2E to Draft #75: new
fulcrum-appimage-real-upgrade-testharness + dedicatedLinux AppImage Upgrade Lifecycleworkflow for x64 and arm64. It downloads the official v0.13.1 and v0.13.2 AppImages, checks both official SHA-256 sidecars, replaces the installed old payload via the pinned RivetAppImageHandoff, launches the actual new AppImage under Xvfb/D-Bus, and requires it to survive the helper health window before commit. This is stronger than fixture-only transaction tests, but it does not yet simulate the installed UI's signed-manifest discovery and click flow. Latest head is13da025f; CI, Product Acceptance, and both architecture E2E jobs are queued.macOS #71 has green CI + Product Acceptance including strict mounted-DMG signature verification. Rivet upstream #300's CI, architecture, native UI, Linux lifecycle and fuzz checks are green; its macOS Embedded Roundtrip job was cancelled, and a rerun has been requested but is still queued. Do not merge #71 until #300's mandatory roundtrip succeeds and the pin is updated to the actual merged upstream commit. macOS #65 remains Draft despite green automation because real installed old→new/rollback has not yet been demonstrated. No release/tag clearance yet.
turinglambdaai commentedon Oct 22, 2026
2026-10-22 further validation update:
replacement-unhealthysurfaced. The helper harness uses a test-only digest stand-in for the corrupted candidate, so signed-manifest discovery/UI remains a separate gate.a94dc171f2713e776bfb97faff46cde001edd4e7; Fulcrum feat(macos): Taskly-style drag-to-Applications DMG and first-launch guide #71 now pins that merged SHA, but macOS CI/acceptance jobs on its updated head are still queued.#73 remains open: macOS real installed upgrade/rollback and app-triggered signed-feed E2E are not proven, nor is Windows in-app MsiHandoff E2E. No v0.13.3 tag or stable release clearance.
turinglambdaai commentedon Oct 22, 2026
Release integration checkpoint (2026-10-22 UTC): #78 is merged into
mainatcb55d66805e44c8e873360b353c77358c8b0a92f. Original source PR heads #65 (macOS native updater), #71 (branded DMG), #75 (AppImage handoff) are all ancestors of main and the redundant PRs were closed.Passed on the exact combined PR head
a95bb2dd5f2e6df539793a8a5b0a74fc55b08da1: CI 39740471865, Product Acceptance 39740472193 including Windows and both macOS architectures, macOS native signed-feed old→new E2E 39740471983 on arm64+x64, Linux AppImage success+rollback lifecycle 39740471864 on arm64+x64. Merged-main CI and acceptance have been triggered but were still queued at the time of this comment.Still required before claiming cross-platform stable in-app self-update parity:
.github/workflows/release.ymlstill unconditionally callsraco rivet release --developmentand auto-publishes the release as stable. Do not tag/publish an unnotarized build as a consumer-grade stable update.No version bump, tag, or release was made in this integration. Current repo VERSION remains
0.13.2; latest published release remainsv0.13.2. Keep issue open until the remaining gates are evidenced.turinglambdaai commentedon Oct 22, 2026
Windows signed-update evidence improved: PR #81 (#81) adds real Ed25519 signed v0.13.2 release-feed discovery on Windows using ordinary backend crypto initialization, verified full MSI download, and signed-manifest-derived native install ticket before exercising existing official installed-MSI failure/retry regression. First workflow execution 39766515395 passed both new signed-feed/MSI checks and installed-upgrade lifecycle. The latest revision's jobs are still running; do not treat earlier green as latest-head clearance. This does not claim an automated UI-to-MsiHandoff/exit/relaunch E2E yet. Production signing work is in PR #80; stable VERSION/tag preflight requires publisher credentials and approval.
turinglambdaai commentedon Oct 22, 2026
2026-10-22 release readiness checkpoint (follow-up to #80):
mainat33ab6b875dc0has green CI and Product Acceptance; that is not production-signing clearance.7cfc9f5+47daa2d: both manually pushed tags and workflow-dispatched release tags must find successful CI and Product Acceptance for the exact tagged SHA before packaging. Stable tags only acceptmainpush runs; RC tags may accept matching PR runs. The static safety guard checks the presence of this gate.04f3d687passed Product Acceptance and the real Windows signed-feed/MSI lifecycle; two macOS CI jobs remained queued. The new head has freshly queued CI/Product Acceptance/MSI runs, so earlier green runs do not authorize merge.Decision: no
VERSIONbump, v0.13.3 tag, or stable publication until #80 latest-head checks, publisher provisioning, and the manual/native acceptance matrix pass. The repository release gate is being hardened, but not yet cleared.turinglambdaai commentedon Oct 27, 2026
2026-10-27 update to the implementation inventory:
mainnow pins Riveta92877cand includes Linux AppImage external handoff and a Linux AppImage upgrade lifecycle workflow. This supersedes the historical v0.12.0/#30 missing-handoff row above, but does not establish all native install/rollback E2E gates. Windows v0.13.3→v0.14.0 MSI smoke is addressed on the pending PR #104. The macOS updater workflow still tested the older v0.13.1→v0.13.2 pair, so PR #107 now upgrades that pinned, test-only signed-feed acceptance to the published v0.13.3→v0.14.0 release pair on arm64 and x64. Keep #73 open pending exact-commit CI, installed-upgrade failure/rollback evidence, package-managed Linux behavior and production release readiness.