feat(release): name a nightly by its commit count on main and its commit #2733

Open

github-sync wants to merge 1 commit from github/pr/2733 into main

github-sync commented

2026-11-12 10:34:15 +00:00

Owner

@hckrman101 opened this pull request on GitHub · 2026-11-12 09:47 UTC · original

Right now a nightly calls itself v2.1.0-rc.3-251-gee29dd55, which looks like a release candidate and can't be compared with another nightly at a glance. After this PR it shows as Nightly 2029 · ee29dd55, and a later nightly always has a higher number.

This is the first of three PRs. The second is #2722, where the 2.x Builder hands over to the launcher. The third is the launcher itself, #2739.

What changed

The name. CI now names every build that isn't for a release tag nightly-<count>-<commit>. That covers the nightly, pull requests and the Actions tab. The count is git rev-list --count HEAD and the commit is 8 hex digits. The name comes from the new scripts/nightly_name.sh, which both build workflows and scripts/linux/appimage.sh use. A build on a tagged commit gets this name too, so it is still known to be the nightly. A local checkout gets the same name from nx2/version.py, plus -dirty when it has changes. A checkout exactly on a release tag keeps the tag. Releases and release candidates are named as before.

Where it shows. Players see "Nightly 2029 · ee29dd55" in:

the menu banner
the start-up screen
Discord
both builders
the game's update question

File names, logs and the update lists keep the plain name. For example, the AppImage is Hookshot-nightly-2029-ee29dd55-x86_64.AppImage, which the existing zsync glob Hookshot-*-x86_64.AppImage.zsync still matches.

The order. Nightlies are ordered by their count, so a nightly is offered only a newer nightly, never an older one. Every new-style nightly is newer than every old git describe one, so current nightly installs move on to the first new nightly.

Nightlies and releases are separate tracks. A nightly name has no version number in it, so it is never compared with a release or a release candidate. In practice:

A builder never switches a game between nightly and release by itself. A nightly game opened with a release builder (or the other way round) keeps Play, and the builder says the game is on another update track. Before this, the Linux builder could rebuild such a folder as the release without asking, and the Windows builder did so with one click and no question.
Switching takes an explicit choice. Picking the other track in the Track menu installs that track's newest build, and the builder asks first: "… is on another update track than …, install it in its place?". The Linux builder passes that answer on to the builder it installs, so the player is asked only once.
Between releases and release candidates nothing changes. They are still in semver order, and the "is older, install?" question works as before.

Windows builder version. MSBuild's Version must be a NuGet version, so the Windows builder's assembly gets 0.0.0-nightly.<count> on a nightly. Nothing reads the assembly version: the builder reads its version from tools/version.txt.

Docs. The rules are in docs/versioning.md, which now also covers:

a local branch ahead of main counts higher than main's nightly, and so isn't offered it;
a pull request's build counts GitHub's merge commit, and nothing published uses that number;
if main were ever rewritten to fewer commits, the following nightlies would count lower than the installed one.

How it was tested

python -I -B tests/run_all.py on Linux: 424 passed, 67 skipped. The only failures are test_bake_portability (no zstandard here) and test_builder_log_read_only (no Tk here), which also fail on main on this PC.
The shared vectors in tests/test_update_tracks.py are now checked against all four implementations: the game's update check (host/hos_update.c), the setup (builder/setup/setup.c), the Linux updater, and the Windows builder's Updater.cs. The vectors cover:
- which track a version is on;
- the order;
- the unordered pairs;
- a change of track;
- how a nightly is shown.
Updater.cs wasn't checked against them before. The new tests/test_update_tracks_cs.py cuts its track rules out of the source and builds them with the .NET SDK.
New Linux builder handler tests (tests/test_linux_downgrade.py):
- a nightly folder opened with a release builder keeps Play, on both the form and the launcher page;
- an explicit track switch asks once;
- the answer is handed to the installed builder, which doesn't ask again.
nx2/test_version.py builds a throwaway git repo and checks the names: on a tag, after it, dirty, and with a tag that isn't a version.
The C parsing (nightly_rank, shown_version, nightly_tag) was run on edge inputs under ASan and UBSan: empty strings, no hash, short or long hashes, 9 and 10 digit counts, -dirty. The Discord name check was tested the same way. hos_update.c and discord_rpc.c compile without warnings with gcc and with llvm-mingw.
The Windows builder builds with -p:Version=0.0.0-nightly.2029. Its informational version reads 0.0.0-nightly.2029+<sha>.

Only checked in CI

The workflows themselves: the Version steps, fetch-depth: 0 on both checkouts that name a version, and the names of the uploaded nightly files.
tests/test_update_tracks_cs.py built for net8.0. This PC has only the .NET 10 SDK, so it ran for net10.0 here.

Not tested

The Windows builder's UI: the new "on another update track" text and the switch question were not run on Windows.
A real update, in either builder or from the game, from an old-style nightly to a new one, or across tracks.
Anything with the game. No game was run.

Screenshots

None. The version shows in the menu banner and on the start-up screen, but both need the game running. This PC has no Tk for the Linux builder, and the Windows builder needs Windows. tests/test_startup_progress.py checks the start-up screen's text, "Nightly 2029 · c544828f".

> [@hckrman101](https://github.com/hckrman101) opened this pull request on GitHub · 2026-11-12 09:47 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2733) Right now a nightly calls itself `v2.1.0-rc.3-251-gee29dd55`, which looks like a release candidate and can't be compared with another nightly at a glance. After this PR it shows as **Nightly 2029 · ee29dd55**, and a later nightly always has a higher number. This is the first of three PRs. The second is #2722, where the 2.x Builder hands over to the launcher. The third is the launcher itself, #2739. ## What changed **The name.** CI now names every build that isn't for a release tag `nightly-<count>-<commit>`. That covers the nightly, pull requests and the Actions tab. The count is `git rev-list --count HEAD` and the commit is 8 hex digits. The name comes from the new `scripts/nightly_name.sh`, which both build workflows and `scripts/linux/appimage.sh` use. A build on a tagged commit gets this name too, so it is still known to be the nightly. A local checkout gets the same name from `nx2/version.py`, plus `-dirty` when it has changes. A checkout exactly on a release tag keeps the tag. Releases and release candidates are named as before. **Where it shows.** Players see "Nightly 2029 · ee29dd55" in: - the menu banner - the start-up screen - Discord - both builders - the game's update question File names, logs and the update lists keep the plain name. For example, the AppImage is `Hookshot-nightly-2029-ee29dd55-x86_64.AppImage`, which the existing zsync glob `Hookshot-*-x86_64.AppImage.zsync` still matches. **The order.** Nightlies are ordered by their count, so a nightly is offered only a newer nightly, never an older one. Every new-style nightly is newer than every old `git describe` one, so current nightly installs move on to the first new nightly. **Nightlies and releases are separate tracks.** A nightly name has no version number in it, so it is never compared with a release or a release candidate. In practice: - **A builder never switches a game between nightly and release by itself.** A nightly game opened with a release builder (or the other way round) keeps **Play**, and the builder says the game is on another update track. Before this, the Linux builder could rebuild such a folder as the release without asking, and the Windows builder did so with one click and no question. - **Switching takes an explicit choice.** Picking the other track in the Track menu installs that track's newest build, and the builder asks first: "… is on another update track than …, install it in its place?". The Linux builder passes that answer on to the builder it installs, so the player is asked only once. - **Between releases and release candidates nothing changes.** They are still in semver order, and the "is older, install?" question works as before. **Windows builder version.** MSBuild's `Version` must be a NuGet version, so the Windows builder's assembly gets `0.0.0-nightly.<count>` on a nightly. Nothing reads the assembly version: the builder reads its version from `tools/version.txt`. **Docs.** The rules are in `docs/versioning.md`, which now also covers: - a local branch ahead of `main` counts higher than `main`'s nightly, and so isn't offered it; - a pull request's build counts GitHub's merge commit, and nothing published uses that number; - if `main` were ever rewritten to fewer commits, the following nightlies would count lower than the installed one. ## How it was tested - `python -I -B tests/run_all.py` on Linux: 424 passed, 67 skipped. The only failures are `test_bake_portability` (no `zstandard` here) and `test_builder_log_read_only` (no Tk here), which also fail on `main` on this PC. - The shared vectors in `tests/test_update_tracks.py` are now checked against all four implementations: the game's update check (`host/hos_update.c`), the setup (`builder/setup/setup.c`), the Linux updater, and the Windows builder's `Updater.cs`. The vectors cover: - which track a version is on; - the order; - the unordered pairs; - a change of track; - how a nightly is shown. `Updater.cs` wasn't checked against them before. The new `tests/test_update_tracks_cs.py` cuts its track rules out of the source and builds them with the .NET SDK. - New Linux builder handler tests (`tests/test_linux_downgrade.py`): - a nightly folder opened with a release builder keeps Play, on both the form and the launcher page; - an explicit track switch asks once; - the answer is handed to the installed builder, which doesn't ask again. - `nx2/test_version.py` builds a throwaway git repo and checks the names: on a tag, after it, dirty, and with a tag that isn't a version. - The C parsing (`nightly_rank`, `shown_version`, `nightly_tag`) was run on edge inputs under ASan and UBSan: empty strings, no hash, short or long hashes, 9 and 10 digit counts, `-dirty`. The Discord name check was tested the same way. `hos_update.c` and `discord_rpc.c` compile without warnings with gcc and with llvm-mingw. - The Windows builder builds with `-p:Version=0.0.0-nightly.2029`. Its informational version reads `0.0.0-nightly.2029+<sha>`. ## Only checked in CI - The workflows themselves: the Version steps, `fetch-depth: 0` on both checkouts that name a version, and the names of the uploaded nightly files. - `tests/test_update_tracks_cs.py` built for net8.0. This PC has only the .NET 10 SDK, so it ran for net10.0 here. ## Not tested - The Windows builder's UI: the new "on another update track" text and the switch question were not run on Windows. - A real update, in either builder or from the game, from an old-style nightly to a new one, or across tracks. - Anything with the game. No game was run. ## Screenshots None. The version shows in the menu banner and on the start-up screen, but both need the game running. This PC has no Tk for the Linux builder, and the Windows builder needs Windows. `tests/test_startup_progress.py` checks the start-up screen's text, "Nightly 2029 · c544828f".

github-sync added 1 commit

2026-11-12 10:34:15 +00:00

feat(release): name a nightly by its commit count on main and its commit 4dbc1be64d

A nightly was named by git describe (v2.1.0-rc.3-251-gee29dd55), which reads as a
release candidate and says nothing a player can compare. CI now names every build
that is not a release nightly-<commit count>-<commit> (scripts/nightly_name.sh), a
checkout the same way (nx2/version.py), and players see it as "Nightly 2029 ·
ee29dd55" in the menu, the start-up screen, Discord, both builders and the update
question.

Nightlies are ordered by their count, and every new name is newer than the old
git describe names. A nightly and a release or release candidate are not ordered:
a builder does not build one over the other unless that track is chosen in the
Track menu, and it asks first. Updater.cs is now checked against the shared track
vectors too (tests/test_update_tracks_cs.py).

github-sync referenced this pull request

2026-11-12 10:34:17 +00:00

feat(launcher): the Hookshot Launcher, one app to build, update and play every version #2739

github-sync referenced this pull request

2026-11-12 10:35:02 +00:00

feat(builder): hand a 2.x install over to the Hookshot Launcher #2722

Commenting is not possible because the repository is archived.

No reviewers