docs(release): the build tools are generic packages, not a tools release #6

Merged

HumanBean merged 2 commits from HumanBean/LongshotLauncher:fix/tools-packages-wording into main

2026-11-13 05:12:30 +00:00

HumanBean commented

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

Owner

Why

scripts/release.py and two comments in Core/ still mention a "tools" release, but the build tools are generic packages now. Longshot's setup also gets a fix for installing the third-party tool into the builder zip's tools/third_party, and the shared docs/releases.md needs the same edit here so the two copies stay identical.

What changed

release: scripts/release.py's docstrings (channel_of, prune) no longer mention the tools release, and the unused TOOLS_TAG constant is gone. The file is byte-identical with Longshot's on its PR: MagicBeanDev/Longshot#117 (MagicBeanDev/Longshot#117).
core: the comments on ReleaseManifest and ToolsLock say the build tools are generic packages. The first URL is Longshot's package; the others are where the archive came from.
docs: docs/releases.md, "Installing": a tool merges, file by file, into a <dest> the builder already has (the Windows zip's LongshotBuilder/tools/third_party). A file both sides have is refused. The file is identical with Longshot's.
tests: in tests/launcher_core/ScreenChecks.cs, the Windows install check's zip now has LongshotBuilder/tools/third_party/a64-kit/lift/a64emit.cpp, and its tools.lock has a third-party tool (a64emit.dll, SDL3.dll). The check verifies that the tool's files land among the zip's sources, on the first install and when the next version keeps the tool, without a second download.

The launcher needed no code change. Toolchains.Unpack writes each file with FileMode.CreateNew into the staging folder, so the tool's files go among the zip's and a file both sides have stops the install. Reuse links or copies a tool by its own recorded files, never by its whole folder.

Testing

python -I tests/test_launcher_core.py, two runs each on main and on this branch, alternating: main 524 checks passed (both runs), this branch 526 checks passed (both runs).
python -I tests/test_release.py: OK on both, two runs each.
cmp scripts/release.py and cmp docs/releases.md against Longshot's branch: identical. RELEASING.md has no "tools release" wording left, and is identical in both repositories.

## Why `scripts/release.py` and two comments in `Core/` still mention a "tools" release, but the build tools are generic packages now. Longshot's setup also gets a fix for installing the `third-party` tool into the builder zip's `tools/third_party`, and the shared `docs/releases.md` needs the same edit here so the two copies stay identical. ## What changed - release: `scripts/release.py`'s docstrings (`channel_of`, `prune`) no longer mention the tools release, and the unused `TOOLS_TAG` constant is gone. The file is byte-identical with Longshot's on its PR: MagicBeanDev/Longshot#117 (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/117). - core: the comments on `ReleaseManifest` and `ToolsLock` say the build tools are generic packages. The first URL is Longshot's package; the others are where the archive came from. - docs: `docs/releases.md`, "Installing": a tool merges, file by file, into a `<dest>` the builder already has (the Windows zip's `LongshotBuilder/tools/third_party`). A file both sides have is refused. The file is identical with Longshot's. - tests: in `tests/launcher_core/ScreenChecks.cs`, the Windows install check's zip now has `LongshotBuilder/tools/third_party/a64-kit/lift/a64emit.cpp`, and its tools.lock has a `third-party` tool (`a64emit.dll`, `SDL3.dll`). The check verifies that the tool's files land among the zip's sources, on the first install and when the next version keeps the tool, without a second download. The launcher needed no code change. `Toolchains.Unpack` writes each file with `FileMode.CreateNew` into the staging folder, so the tool's files go among the zip's and a file both sides have stops the install. `Reuse` links or copies a tool by its own recorded files, never by its whole folder. ## Testing - `python -I tests/test_launcher_core.py`, two runs each on main and on this branch, alternating: main 524 checks passed (both runs), this branch 526 checks passed (both runs). - `python -I tests/test_release.py`: OK on both, two runs each. - `cmp scripts/release.py` and `cmp docs/releases.md` against Longshot's branch: identical. `RELEASING.md` has no "tools release" wording left, and is identical in both repositories.

HumanBean added 2 commits

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

docs(release): the build tools are generic packages, not a tools release c3e1642f36

release.py's docstrings still named the tools release, and TOOLS_TAG,
used nowhere, described it; so did two comments in Core. release.py is
byte-identical with Longshot's (MagicBeanDev/Longshot, the same change).

docs(releases): a tools.lock tool merges into a folder the builder has

CI / Conventional Commit title (pull_request) Successful in 5s

Details

CI / Compile and test (pull_request) Successful in 1m5s

Details

399894c704

The Windows builder zip has LongshotBuilder/tools/third_party, which is
also the third-party tool's dest. The launcher unpacks file by file
(FileMode.CreateNew), so the tool's prebuilt files go among the zip's
sources and a file both have is refused: the check now covers it, on a
first install and when the next version keeps the tool. docs/releases.md
stays identical with Longshot's, whose setup gets the same rule.

HumanBean referenced this pull request from MagicBeanDev/Longshot

2026-11-13 05:01:40 +00:00

fix: the setup merges the third-party tool into the builder's third_party, and the Hookshot item is back #117

HumanBean referenced this pull request from a commit

2026-11-13 05:12:14 +00:00

fix: the setup merges the third-party tool into the builder's third_party, and the Hookshot item is back (#117)

HumanBean merged commit 5ab10e3fd0 into main

2026-11-13 05:12:30 +00:00

HumanBean deleted branch fix/tools-packages-wording

2026-11-13 05:12:30 +00:00

HumanBean referenced this pull request from a commit

2026-11-13 05:12:31 +00:00