Sign up
View stargazersSign up

Complete release notes, signing, Homebrew delivery, and automatic updates#82

opened15d agobySSamanyu Das

Note

🤖 Claude Opus 5.5 responding on behalf of Sam

Draft type: release delivery tracker. Source: feedback point 6. Release scope: v1 release blocker.

What to build

Deliver one versioned release with release notes, Developer ID signing, Apple notarization, Homebrew cask installation, and Sparkle updates. Start by identifying the existing release machinery and its unverified or missing steps. Track separate implementation gaps as child tickets rather than rebuilding working parts.

Acceptance criteria

  • Identify the release candidate by version, app revision, bundled engine revision, and artifact hashes.
  • Set up a repeatable workflow that generates release notes and a versioned changelog without hand-editing generated files.
  • Verify app and helper signing, notarization, and installation from the distributed disk image.
  • Publish and verify the requested Homebrew tap and cask against that release artifact.
  • Verify a signed Sparkle feed and an update from an earlier installed version.
  • Default update checks run daily and ask before installation.
  • If the user enables automatic updates, Miri installs them silently in the background at startup.
  • An update preserves user settings and leaves a working app when the update fails or is interrupted.
  • Record release prerequisites, credential owners, and missing acceptance evidence without requesting secrets in issue text.

Verification

Use the distributed release artifact for a clean install, a Homebrew install, and an update. Verify the installed app and actual helper identity after each path. Development ad-hoc signing does not establish release signing or notarization.

Technical approach

Use GitHub's generated release notes as the starting point for each tagged release. Review those notes against the actual artifact before publication. Generate the changelog from published release records through a rerunnable workflow. Use the same reviewed notes for the release and update presentation to avoid divergent change lists. This is a proposed implementation approach, not an existing workflow. GitHub documents generated release notes and label-based grouping. Sparkle, Developer ID signing, notarization, and Homebrew delivery remain the accepted release direction.

The release scope already accepts signing, notarization, Sparkle, and a Homebrew cask. Issue #83 audits release readiness independently of packaging progress.

Blocked by

None for inventory and preparation. Public release remains gated by required acceptance evidence and signing credentials.

SSamanyu Das15d ago

Note

🤖 Claude Opus 5.5 responding on behalf of Sam

Triage, 26 October 2026: this issue stays needs-triage. It is a v1 release blocker, but it is a broad tracker that combines code preparation with Developer ID, notarization, and update-signing access. The access steps are human-only, and enrollment is still marked pending in the current source. Next step: split it into bounded child tasks, with the access steps labelled ready-for-human.