JesseandClaude Opus 5
bd802cb512
Submodule pinned to v0.7.9 (6058f6c), current.ts bumped in place, release
notes rewritten in all five locales, README.md and instructions.md
updated. No new version file and no migration: the outgoing 0.7.8:0's
`up` was empty, which is versions.md's common case.
GAMES IN PROGRESS DO NOT CARRY OVER, and both docs lead with it.
v0.7.9 changes a rule. advance.ts gated §3.4's collision check on
`mode === 'competitive' || mode === 'coop'`, while SOLO_CONFIG carried
both limits (3 a Day, 5 total) and the setup screen offered them as live
settings with "the game ends in a loss" printed beside them. A solitaire
player could set a limit of 1 and crash all game. Jesse's ruling was that
the settings do what they say, so the gate went rather than the controls.
A solitaire save is { seed, history, rules? } where `rules` is the house
rules only — the collision caps are NOT in the save, so a restore takes
today's defaults. A 0.7.8 save therefore replays under live caps and
stops at the move that crossed one.
MEASURED WITH A CONTROL, because two earlier attempts at measuring it
were wrong. With the caps disabled, 1200 of 1200 generated solitaire
saves replay every intent — that is the control. Of those, 74 games
crossed the 5-collision total and 70 of the 74 truncate once the caps
are enforced; one replays 141 of its 532 intents and stops. So it is
"will break for anyone who crashed", not "may break". The earlier run
that reported no breakage had in fact been failing every replay at
intent 2 on an unrelated house-rules mismatch, and said nothing at all —
the control is the only reason that was caught.
It fails safe: the save is left untouched and the game declines to open
rather than loading a position the rules could not have produced, so a
player who cares can put 0.7.8 back and finish. Nothing in this package
can act on it either way — a solitaire save lives in the player's own
browser, not on this server. MULTIPLAYER GAMES ARE UNAFFECTED:
competitive and coop have been inside that gate all along.
TWO THINGS FIXED IN PASSING, both pre-existing and both in the way of
the release check. UPDATING.md was not prettier-formatted. And there was
no .prettierignore, so `prettier --check .` walked the bundled
application — a separate repo with its own style, which this package does
not own and does not commit — and reported 171 warnings it could do
nothing about. That check now passes clean, which is the point of having
it in the release sequence at all.
Verified: npm run check clean, prettier clean, make x86 packs as
v0.7.9:0. NOT yet installed on a box and NOT played.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YTaNBL1jVxNqgFdjHkHoo3
4.0 KiB
Updating the upstream version
Station Master is built from a git submodule at station-master/ (tracking
Jesse.Markowitz/station-master, a
self-hosted Gitea repo — this is Jesse's own game, not a third-party upstream, but it is packaged
the same way: Dockerfile builds whatever commit the submodule points at, with no pinned
dockerTag in the manifest. The submodule pin is the version.
Station Master tags its releases (v0.5.1, …) at the commit that bumped package.json. Nothing
else about this package should need to change for a bump — not the Dockerfile, not main.ts,
not the manifest — only the submodule pin and this package's own version (below).
Determining the upstream version
cd station-master && git fetch --tags && git tag -l --sort=-v:refname | head -5
The current pin is the submodule's checked-out commit:
git submodule status station-master
Applying the bump
cd station-master && git fetch --tags && git checkout v<new version>
cd .. && git add station-master
Then set this package's version in startos/versions/current.ts to the same number, as
<tag>:0 — versions.md's consistency checklist requires the upstream half to match the
submodule tag exactly, so v0.5.3 becomes 0.5.3:0. Give it release notes naming what changed for
a player, then rebuild (make). Raise the :0 instead, leaving the upstream half alone, when the
change is packaging-only and the bundled game has not moved.
The initial release shipped as
1.0.0:0— the scaffold's placeholder, left in by mistake while the game was at 0.5.1. It was corrected to0.5.2:0before the package was ever published anywhere, which is the only reason a downgrade was harmless:0.5.2:0sorts below1.0.0:0, so an installed copy had to be removed rather than updated over.
Building a test package from work that is not pushed yet
The Dockerfile copies station-master/ out of the build context, so what is packed is whatever is
in that directory — the submodule's pin only matters for reproducibility, not for make. That is
what makes it possible to put a build on a test box before the game is committed, tagged or pushed,
which is how v0.7.0 was played before release:
# point the submodule at a local commit that exists nowhere else yet
cd station-master && git fetch --no-tags /path/to/station-master main && git checkout --detach FETCH_HEAD
# or, for work that is not even committed, copy the working tree in
rsync -a --delete --exclude .git --exclude node_modules --exclude dist \
/path/to/station-master/ station-master/
cd .. && make x86 && make install
Move the DOWNSTREAM digit for each test build — 0.7.0:1, :2, :3. StartOS installs an
update, not a re-install, so a rebuild at the same version has nothing to install over; and the
downstream half is exactly the right one to move, since the upstream game has not been released
again between two test packs. Whichever digit the box ends up on is the one the real release should
carry: publishing a lower one afterwards is a downgrade the box will refuse.
Before committing the wrapper, put the pin back on a real tag — a submodule pointing at a commit that only exists on one machine is a package nobody else can build:
cd station-master && git fetch --tags origin && git checkout v<version>
cd .. && git add station-master
The pack's git stamp says -modified for the whole of this, which is the flag that a build came
from a dirty tree. Never publish one of those.
If the jump carries a multiplayer protocol or persistence-format change (check the game repo's
CHANGELOG.md and docs/architecture/multiplayer.md), read it before bumping: a running
server's saved games are stamped with engineVersion and refuse to resume under a mismatched
one (src/server/index.ts in the game repo) — nothing in this package works around that, so an
in-progress game must finish (or be accepted as lost) before an incompatible bump.