feat(update): an update track (Release, Release candidate, Nightly) in the builders and the game #2061

Merged

hckrman101 merged 1 commit from update-tracks into main

2026-11-11 01:33:49 +00:00

hckrman101 commented

2026-11-11 01:33:01 +00:00

(Migrated from github.com)

Release candidates and nightlies could not be installed or kept up to date with the builder: every updater compared the installed version with GitHub's latest release, which leaves out prereleases. RC users were pushed back to the older release, and a nightly could not be installed at all.

What failed

Windows Builder (Updater.cs LatestTag, MainWindow.RefreshMode): an RC or nightly builder saw v2.0.14 as "available" and put up Update builder, which installed the latest release (RunLatestSetup reads releases/latest). An RC builder could not build until it had downgraded itself.
Setup (setup.c manifest_url): started with no --tag, the HookshotBuilder.exe from an RC's or the nightly's release page installed the latest release. --tag nightly failed, because the nightly's list names v2.1.0-rc.1-3-g…, not nightly ("GitHub answered with the setup list of …").
Game (hos_update.c, Windows and Linux): strcmp(latest, have), so an RC or nightly folder was asked to "update" to the older release on every start, and Yes downgraded it.
Linux (linux_update.py): release_key ignored the RC number (rc.2 == rc.1), so an RC was never offered the next RC, and a nightly never got the next nightly. The RC AppImage's zsync update info named latest, so AppImageUpdate took it back to the older release.
Nightly identity: git describe without --long named the nightly of an RC-merge commit exactly like the RC (v2.1.0-rc.1).

What changes

An Update track menu in the Windows and Linux builders: Release / Release candidate / Nightly. It defaults to the installed build's track (from its version) and is saved once picked (builder-settings.json / the Linux config).
- Release: the latest release, as before.
- Release candidate: the newest of the RCs and releases by semver (/releases?per_page=20, falling back to latest), offered only when newer. It never goes back to an older release, and it offers v2.1.0 once that ships.
- Nightly: the nightly release's list tag line, offered when it is a different build.
- Switching track installs that track's newest build, with a confirmation when it is older.
The game's update check follows the folder's track, using the same rules.
The setup maps a nightly version to the nightly release. RC and nightly setups are built with HOOKSHOT_SETUP_RELEASE, so with no --tag they install their own release.
Nightly versions use git describe --long (…-0-g<sha> on a tagged commit). The RC AppImage's zsync update info names its own tag.
docs/versioning.md: a new Update tracks section.

Existing installs

Clients already installed keep their old logic until they update:

Release users see no change: the Release track makes the same requests and comparisons as before.
Builds already installed from v2.1.0-rc.1 or the nightly still see v2.0.14 as an update and downgrade if they accept. To get out of that, install the next RC or nightly by hand once, from a setup built with this change. From then on they follow their track.

Tests

tests/test_update_tracks.py covers which track a version is on, semver order (rc.10 > rc.9, 2.1.0 > 2.1.0-rc.2), the newest RC or release from a release list, which URL each track asks, and the update target for each track. It checks linux_update.py and the C helpers compiled from hos_update.c and setup.c. tests/test_linux_update.py still passes.

Untested: the Windows Builder (C#/XAML) was not compiled locally (no .NET here), so it relies on CI. The Windows half of hos_update.c and setup.c were not compiled (no mingw here; the shared helpers are compiled by the test). Neither builder UI has been run, and no real update has gone through any track.

Release candidates and nightlies could not be installed or kept up to date with the builder: every updater compared the installed version with GitHub's *latest* release, which leaves out prereleases. RC users were pushed back to the older release, and a nightly could not be installed at all. ## What failed - **Windows Builder** (`Updater.cs` `LatestTag`, `MainWindow.RefreshMode`): an RC or nightly builder saw `v2.0.14` as "available" and put up **Update builder**, which installed the latest release (`RunLatestSetup` reads `releases/latest`). An RC builder could not build until it had downgraded itself. - **Setup** (`setup.c` `manifest_url`): started with no `--tag`, the `HookshotBuilder.exe` from an RC's or the nightly's release page installed the latest release. `--tag nightly` failed, because the nightly's list names `v2.1.0-rc.1-3-g…`, not `nightly` ("GitHub answered with the setup list of …"). - **Game** (`hos_update.c`, Windows and Linux): `strcmp(latest, have)`, so an RC or nightly folder was asked to "update" to the older release on every start, and Yes downgraded it. - **Linux** (`linux_update.py`): `release_key` ignored the RC number (`rc.2 == rc.1`), so an RC was never offered the next RC, and a nightly never got the next nightly. The RC AppImage's zsync update info named `latest`, so AppImageUpdate took it back to the older release. - **Nightly identity**: `git describe` without `--long` named the nightly of an RC-merge commit exactly like the RC (`v2.1.0-rc.1`). ## What changes - An **Update track** menu in the Windows and Linux builders: Release / Release candidate / Nightly. It defaults to the installed build's track (from its version) and is saved once picked (`builder-settings.json` / the Linux config). - Release: the latest release, as before. - Release candidate: the newest of the RCs and releases by semver (`/releases?per_page=20`, falling back to latest), offered only when newer. It never goes back to an older release, and it offers `v2.1.0` once that ships. - Nightly: the `nightly` release's list `tag` line, offered when it is a different build. - Switching track installs that track's newest build, with a confirmation when it is older. - The game's update check follows the folder's track, using the same rules. - The setup maps a nightly version to the `nightly` release. RC and nightly setups are built with `HOOKSHOT_SETUP_RELEASE`, so with no `--tag` they install their own release. - Nightly versions use `git describe --long` (`…-0-g<sha>` on a tagged commit). The RC AppImage's zsync update info names its own tag. - `docs/versioning.md`: a new *Update tracks* section. ## Existing installs Clients already installed keep their old logic until they update: - Release users see no change: the Release track makes the same requests and comparisons as before. - Builds already installed from v2.1.0-rc.1 or the nightly still see `v2.0.14` as an update and downgrade if they accept. To get out of that, install the next RC or nightly by hand once, from a setup built with this change. From then on they follow their track. ## Tests - `tests/test_update_tracks.py` covers which track a version is on, semver order (`rc.10 > rc.9`, `2.1.0 > 2.1.0-rc.2`), the newest RC or release from a release list, which URL each track asks, and the update target for each track. It checks `linux_update.py` and the C helpers compiled from `hos_update.c` and `setup.c`. `tests/test_linux_update.py` still passes. Untested: the Windows Builder (C#/XAML) was not compiled locally (no .NET here), so it relies on CI. The Windows half of `hos_update.c` and `setup.c` were not compiled (no mingw here; the shared helpers are compiled by the test). Neither builder UI has been run, and no real update has gone through any track.

Arkex-ai commented

2026-11-11 01:36:47 +00:00

(Migrated from github.com)

One Linux source regression from the update-track change: on main 6cecdd18, python3 -I -B tests/test_make_game_ngx.py runs 17 tests with one error. The authored Builder stub in test_toggling_dlss_on_up_to_date_folder_offers_update lacks the new switching() method used by apply_mode. The same 17 tests passed on the older 48:9 integration. The release-track tests and actual GUI are outside this reproduction.

One Linux source regression from the update-track change: on main `6cecdd18`, `python3 -I -B tests/test_make_game_ngx.py` runs 17 tests with one error. The authored Builder stub in `test_toggling_dlss_on_up_to_date_folder_offers_update` lacks the new `switching()` method used by `apply_mode`. The same 17 tests passed on the older 48:9 integration. The release-track tests and actual GUI are outside this reproduction.