sky_line/Slipstream

Fork 1

Update check: notify when a new Slipstream version is available (foundation for an auto-updater) #293

New issue

Closed

opened 2026-10-04 12:22:27 +00:00 by sky_line · 1 comment

sky_line commented

2026-10-04 12:22:27 +00:00

Owner

Let the viewer tell users when a newer Slipstream is out, as a first step that may grow into a full auto-updater later.

Phase 1: update check + notification

Source of truth: a small static JSON on our own site, e.g. https://slipstreamviewer.org/update/<channel>.json (channels beta / release), generated by the release CI or the website build from releases.yml. Fields: version, build, tag, date, release-notes URL, per-platform download URLs, sha256, minimum supported version, and an optional "critical" flag.
- Static file, not the Forgejo API: cacheable through Cloudflare, no rate limits, no auth, and we control the format. It is also what a later updater would read.
Viewer:
- Check once at startup (after login, deferred to idle, never before the UI exists), then every ~24 h while running. Async via the existing HTTP core (coroutine); never blocks a frame. Follow the viewer's proxy settings.
- Compare against the running version and channel (build_data.json / LLVersionInfo). A beta user sees both newer betas and newer releases; a release user sees releases only.
- Notify with a non-modal notification: "Slipstream X.Y.Z is available", with buttons Release notes, Download (opens the right download for this platform/format) and Skip this version. Remember skipped versions.
- Package-managed installs (.deb via apt, Flatpak, AUR): say "Update through your package manager (apt / flatpak update / AUR helper)" instead of offering a download. Detect via the wrapper's .packaged-by marker / Flatpak env.
- Preferences: "Check for updates" on/off (default on) and a "Check now" button (Help menu entry too). Respect an enterprise/lab override setting.
- Privacy: the request carries no user data beyond what any HTTP GET does (no IDs, no telemetry). Document this.
Security: HTTPS only. Ideally the JSON is signed (detached signature with the release key, #288), and the viewer verifies it before trusting download URLs. That is a requirement before Phase 2 and nice to have in Phase 1.

Phase 2 (later): auto-updater

Windows: download the signed Setup.exe (Authenticode, #287), verify sha256 + signature, run it on exit or with "Restart now".
Linux tarball: download, verify (SHA256SUMS.asc), swap the install dir atomically, relaunch. Package-managed installs keep deferring to their package manager.
Delta updates, background download with a progress UI, rollback on a failed start.

Done when (Phase 1)

Running Beta N while Beta N+1 is published shows the notice within a minute of login, with working notes and download links for the user's platform/format.
Skip silences that version; turning the setting off stops all checks.

Let the viewer tell users when a newer Slipstream is out, as a first step that may grow into a full auto-updater later. ### Phase 1: update check + notification - **Source of truth:** a small static JSON on our own site, e.g. `https://slipstreamviewer.org/update/<channel>.json` (channels `beta` / `release`), generated by the release CI or the website build from `releases.yml`. Fields: version, build, tag, date, release-notes URL, per-platform download URLs, sha256, minimum supported version, and an optional "critical" flag. - Static file, not the Forgejo API: cacheable through Cloudflare, no rate limits, no auth, and we control the format. It is also what a later updater would read. - **Viewer:** - Check once at startup (after login, deferred to idle, never before the UI exists), then every ~24 h while running. Async via the existing HTTP core (coroutine); never blocks a frame. Follow the viewer's proxy settings. - Compare against the running version and channel (`build_data.json` / LLVersionInfo). A beta user sees both newer betas and newer releases; a release user sees releases only. - Notify with a non-modal notification: "Slipstream X.Y.Z is available", with buttons **Release notes**, **Download** (opens the right download for this platform/format) and **Skip this version**. Remember skipped versions. - **Package-managed installs** (.deb via apt, Flatpak, AUR): say "Update through your package manager (apt / flatpak update / AUR helper)" instead of offering a download. Detect via the wrapper's `.packaged-by` marker / Flatpak env. - Preferences: "Check for updates" on/off (default on) and a "Check now" button (Help menu entry too). Respect an enterprise/lab override setting. - Privacy: the request carries no user data beyond what any HTTP GET does (no IDs, no telemetry). Document this. - **Security:** HTTPS only. Ideally the JSON is signed (detached signature with the release key, #288), and the viewer verifies it before trusting download URLs. That is a requirement before Phase 2 and nice to have in Phase 1. ### Phase 2 (later): auto-updater - **Windows:** download the signed `Setup.exe` (Authenticode, #287), verify sha256 + signature, run it on exit or with "Restart now". - **Linux tarball:** download, verify (`SHA256SUMS.asc`), swap the install dir atomically, relaunch. Package-managed installs keep deferring to their package manager. - Delta updates, background download with a progress UI, rollback on a failed start. ### Done when (Phase 1) - Running Beta N while Beta N+1 is published shows the notice within a minute of login, with working notes and download links for the user's platform/format. - Skip silences that version; turning the setting off stops all checks.

sky_line added the

platform

feature

labels

2026-10-04 12:22:27 +00:00

sky_line referenced this issue

2026-10-05 11:03:23 +00:00

Auto-updater for Windows and Linux tarball installs (signed feed, background download, verified apply, rollback) #421

sky_line added this to the 1.1.0 milestone

2026-10-05 17:02:31 +00:00

sky_line referenced this issue from a commit

2026-10-05 19:39:01 +00:00

Update feeds for the viewer's update check: /update/release.json and beta.json

sky_line referenced this issue from a commit

2026-10-05 19:39:02 +00:00

Update check: tell people when a newer Slipstream is out (phase 1)

sky_line added this to the Slipstream project

2026-10-06 15:04:14 +00:00

sky_line referenced this issue from a commit

2026-10-06 20:15:40 +00:00

Setup: offer betas to release builds on request; drop LL updater leftovers

sky_line commented

2026-10-07 22:01:01 +00:00

Author

Owner

Ticket audit 2026-10-07: done and shipped in 1.1.0 Beta 2. Update check against the release feed with notes / download / skip, package-manager detection and Check now (16fc639d60, 0a86ed896e, 9eaebb654a). The auto-updater is a separate later phase (#421). If you still see the problem on the current beta, please reopen or file a new report.

Ticket audit 2026-10-07: done and shipped in **1.1.0 Beta 2**. Update check against the release feed with notes / download / skip, package-manager detection and Check now (16fc639d60, 0a86ed896e, 9eaebb654a). The auto-updater is a separate later phase (#421). If you still see the problem on the current beta, please reopen or file a new report.

sky_line closed this issue

2026-10-07 22:01:01 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sky_line/Slipstream#293

No description provided.

Rows
Columns