Jesse
ea012f1329
Submodule pin moves to v0.5.2, which carries the working splash-page
multiplayer door and the GET /api/health probe behind it.
The interface goes back to serving `/` — the splash, which is the front
door to all three ways to play. It pointed at /play.html only because the
splash's multiplayer door was hardcoded to "Coming soon", making the front
page a dead end on a real server; v0.5.2 removes the reason for the
workaround. The splash now probes /api/health on load, so served from here
it opens the lobby and served as a plain static site it says plainly that
it needs a server.
The package version was wrong and is corrected: 1.0.0:0 -> 0.5.2:0. That
1.0.0 was the scaffold's placeholder, left in by mistake — versions.md's
consistency checklist requires the upstream half to match the bundled tag,
which is what makes "bump the pin, bump the version" one mechanical action
rather than a judgement call. No historical version file is needed: the
placeholder carried no migration and was never published anywhere.
The correction is a downgrade in ExVer terms, so StartOS refused to install
over the existing copy ("uninit target range `!` is unsatisfiable"). The
installed package was therefore removed and reinstalled — checked first
that the volume held only an auto-generated join secret and no games. Two
consequences, both one-time and both recorded in UPDATING.md: the join
secret is regenerated, and the host's public domain binding was dropped
with the uninstall and has to be re-added.
Verified on phoenix.local: builds as v0.5.2:0, installs, starts, and serves
/api/health 200 with the right body; the splash carries all three doors
including a live ./play.html?lobby, no "Coming soon" anywhere, all three
ids the probe addresses present, and #lobby rendering on play.html?lobby.
2.3 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.
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.