Open source AI projects with GitHub releases in the past day, and what actually happens after the tag is published

For this guide the bar is: (1) source code publicly available on GitHub under an OSI-approved license, (2) a GitHub Release (not just a commit or a tag) published within the past 24-48 hours, (3) the release ships a usable binary or package, not just a version bump. A lot of lists that surface for this query skip the binary requirement. The interesting projects are the ones that actually deliver something a user can run, not just projects that cut a tag and walk away.

Because the listicles already list the projects. What the listicles never explain is what happens after the tag is published: how the signed zip moves from github.com/owner/repo/releases/download/... to the user's /Applications/ directory, how signatures are verified, how the channel routing works, and what happens when a release crashes on boot. Fazm is a useful case because its release pipeline is entirely in the open repo and every step of 'what happens when a new GitHub release drops' is readable source, not a black box.

Two source files. Backend/src/routes/appcast.rs lines 12-19 declare `const GITHUB_REPO: &str = "mediar-ai/fazm";`, `const GITHUB_API: &str = "https://api.github.com";`, and `const MIN_SUPPORTED_VERSION: &str = "2.1.0";`. Lines 239-255 are the GitHub releases fetch. Line 47 sets `public, max-age=60` on the appcast response. Line 151 is the regex that extracts the EdDSA signature from the GitHub release body. Desktop/Sources/UpdateRollbackManager.swift lines 25-27 set `crashThreshold = 3` and `rapidCrashWindow = 60`. All four facts come from github.com/mediar-ai/fazm, open source.

Nine. From CHANGELOG.json: v2.0.1 (April 3), v2.0.6 (April 4), v2.0.7 (April 5), v2.0.9 (April 5), v2.1.2 (April 7), v2.1.3 (April 9), v2.2.0 (April 11), v2.2.1 (April 12), and v2.3.2 (April 16). One 'past day' release is common. Nine in 13 days means there is almost always one within the past 24-48 hours. The cadence is not accidental: the appcast backend polls GitHub releases on every request with a 60-second cache, so the moment a new tag with a .zip asset is published, every existing Fazm install will discover it within 10 minutes (the Sparkle `updateCheckInterval`, UpdaterViewModel.swift line 361).

appcast.rs at generate_appcast() does it in one pass. It calls `api.github.com/repos/mediar-ai/fazm/releases?per_page=20` in parallel with a Firestore fetch for channel routing, finds the release asset whose name ends in .zip and does not contain 'appcast', parses the tag via the regex `v?(\d+\.\d+\.\d+)(?:\+(\d+))?(?:-macos)?(?:-(staging|beta))?`, pulls the EdDSA signature out of the release body with another regex, converts the 'What's New' section of the release body into HTML list items, and emits one <item> per (release, channel) pair. No cron job, no webhook. Every appcast.xml request does the live fetch with a 60-second CDN cache.

Firestore holds a `desktop_releases` collection where each document is a tag-to-channel assignment (stable, beta, staging). On every appcast request, the backend fetches that map in parallel with GitHub and uses Firestore as the authoritative source. If Firestore is unreachable, it falls back to the tag suffix heuristic: `-staging` suffix means staging channel, otherwise stable. The reason Firestore exists on top of GitHub's isPrerelease flag is that Fazm supports three channels (stable / beta / staging), not two, and Fazm promotes releases between channels after the tag has already been published. Changing a channel should not require re-cutting a release.

UpdateRollbackManager.swift ships three phases. Phase 1 fires inside Sparkle's willInstallUpdate delegate: it runs /usr/bin/ditto to copy the current /Applications/Fazm.app into ~/Library/Application Support/Fazm/UpdateBackup/. Phase 2 runs on every launch: it reads two UserDefaults keys, `rollback_launchCount` and `rollback_launchTimestamp`. If three launches happen with less than 60 seconds between each, we are in a crash loop. Phase 3 restores the backup over the broken app, writes `rollback_blockedVersion = <crashing version>`, and Sparkle's shouldProceedWithUpdate delegate then refuses that version (UpdaterViewModel.swift lines 92-101). The two thresholds are literal values in the source: `crashThreshold = 3` and `rapidCrashWindow = 60`, lines 25-27.

Because the Fazm team needed to enforce a hard floor for a paywall and auth change that shipped in v2.1.0. Sparkle's criticalUpdate tag tells any client below that version to show a non-skippable prompt on the next check. Every version below 2.1.0 effectively has to update. This is the reason `MIN_SUPPORTED_VERSION` is a const in appcast.rs rather than a config value: changing the floor requires a backend deploy, which is the same blast radius as changing the paywall logic itself.

Yes. The release notes include a line of the form `edSignature: MEUCIQD...` or similar. The backend regex at appcast.rs line 151 extracts any Base64 string of 40 or more characters that follows the literal `edSignature`. Sparkle on the client then verifies that signature against the Fazm EdDSA public key baked into Info.plist before extracting the zip. If the signature is missing, malformed, or does not verify, Sparkle refuses to install. verify-release.sh in the repo root runs this end-to-end: it downloads the appcast, extracts the edSignature and download URL, fetches the zip, and runs the sign_update --verify tool from Sparkle's bin/ directory. No install, just verification.

Screenshot-based agents have a very different release surface: they ship model weights and a thin client. Fazm ships a binary that reads the macOS accessibility tree directly via AXUIElementCreateApplication and AXUIElementCopyAttributeValue (AppState.swift line 439 area). The update path has to ship the binary, not just model weights, so the infrastructure described in this guide (Sparkle, EdDSA, ditto backup, crash-loop rollback) is required. A screenshot-based cloud agent can roll out a new model with a Firestore feature flag and no client release. Different shape of past-day release.

Yes. The three load-bearing pieces are: (1) a small HTTP endpoint that polls api.github.com/repos/OWNER/REPO/releases and emits a Sparkle appcast (150 lines of Rust, or ~200 of Go/Node), (2) Sparkle framework on the client with EdDSA signing (generate_keys once, sign_update per release, store the public key in Info.plist's SUPublicEDKey), (3) a rollback manager on the client that tracks launch timestamps in UserDefaults and keeps a backup of the current .app bundle. Every file in Fazm's repo that implements this is open-source: Backend/src/routes/appcast.rs, Desktop/Sources/UpdateRollbackManager.swift, Desktop/Sources/UpdaterViewModel.swift, release.sh, verify-release.sh.