raw.githubusercontent.com caches branch-named files, so the installer was serving a stale zip after CI rewrote builds.
Co-authored-by: Cursor <cursoragent@cursor.com>
Releases and version numbers are gone. CI now rebuilds all three platforms
on every change to main and commits the packages to the `builds` branch,
so what anyone downloads is the current state of the repository. The
branch is rewritten from scratch each time rather than added to, so the
repository keeps one copy of the packages instead of a ~70 MB set per
commit.
Without tags there is no version to compare, so a build carries the
commit it was made from and the branch carries a VERSION file naming the
same commit. The updater fetches those few bytes and treats any
difference as being behind; commits are not ordered, and the branch only
ever holds the current build.
The installers fetch from the branch over raw.githubusercontent.com for
the same reason.
Co-authored-by: Cursor <cursoragent@cursor.com>
Each installer carries no application of its own and resolves
/releases/latest/download/ at the moment it runs, so the file never goes
stale and the same download keeps working across future releases.
macOS installs into /Applications, falling back to the user's own folder
when that is not writable, and clears the quarantine flag the unsigned
build would otherwise trip over. Windows extracts over any existing
install rather than replacing the folder, so the progress files kept
inside it survive, and adds a Start menu entry. Linux drops the AppImage
in ~/Applications with a desktop entry and its icon.
Publish the macOS one zipped, because a release asset loses its
executable bit and a .command needs one to be double-clicked.
The .cmd also had to be excluded from the *.cmd ignore rule, which comes
from the kernel section of the template and targets build artifacts.
Co-authored-by: Cursor <cursoragent@cursor.com>
