mirror of
https://github.com/Felitendo/spotifast.git
synced 2026-11-01 17:33:26 +01:00
Carmine Paolino
cd0bf03308
Checking for, downloading, verifying and installing an update now go through fastframe-update, configured for Spotifast: its repository and names, Fastpotify's legacy names and Windows location, the macOS bundle ids and renamed executables, and no publisher key until releases are signed (checksums.txt alone, as before). The crate's reqwest transport runs on Spotifast's blocking client with its proxy. fastframe_update::intercept runs first in main: `--apply-update <job>` makes the process the helper, which exits before anything else, and `--update-receipt` and `--update-error` are taken out before clap parses the rest, so the hidden flags leave Cli. The handoff and receipt formats are unchanged (the crate's compat tests read Spotifast 0.10.1's), the update interface and its tests stay, and a new test checks that both commands accept the update flags and that the helper runs before the app. The updater tests of the deleted modules move to the crate. Behaviour changes: - The macOS helper runs from a copy of the whole bundle in the staging folder, not from the installed bundle, so moving and restoring the installed bundle never touches the helper's own code. - A Nix install says "Update this installation with Nix." and a Homebrew one "Update this installation with Homebrew.", where both said "with Nix or Homebrew". - The old portable layout of 0.8.0 and 0.9.0 is no longer recognised in a downloaded archive; no release older than 0.10 can be offered. - Before the Windows setup program left a marker, its current default location Programs/Spotifast/spotifast.exe is recognised as well as Programs/Fastpotify/fastpotify.exe. - The release check runs on the blocking client like the download, with the updater's own headers and redirect rules.