f4fef294286539108f9cb8095aab76a782260d76
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CydandClaude Opus 5
|
eb17220dd5 |
Test builds go stale after a fortnight
A tester still racing a two-week-old binary reports things that were fixed a week ago, and the afternoon spent chasing them is gone. An expired build now says so and stops: a dialog naming its version and expiry date, pointing at the releases page, and an exit before anything else runs. The log carries the same line, so a report from an expired build identifies itself. $expireDays at the top of stamp-version.ps1 is the shelf life, sitting next to the product line it belongs with. It counts from the day a build was MADE rather than the day the code was written - rebuilding an old commit to chase something should hand back a usable binary, not one born stale. SET IT TO 0 FOR A REAL RELEASE. A shipped build that expires is a catastrophe, and that one line decides it. It is called out in the script, in the generated header and in BUILD.md, because it is the kind of thing that gets noticed exactly once, too late. The date is what makes rpl4build.h differ from one day to the next, so the first build of each day recompiles RPL4.CPP and the rest do not. This is a nudge, not a lock. The date comes from the machine's own clock and anyone determined can wind it back; the point is to stop an honest tester wasting a day, not to stop anybody at all. RP412NOEXPIRY=1 waives it for us and logs that it did, so a waived build is never mistaken for a current one. It is deliberately absent from environ.ini - a bypass every tester can see is a bypass every tester will use, and then it never goes stale for the one person it was meant to stop. Verified all four ways by backdating the shelf life rather than touching the clock, which is what a negative $expireDays is for: a fresh build runs untouched; an expired one raises the dialog, exits 1, and logs "Build expired on 4 August 2026 - refusing to run"; the same expired build with RP412NOEXPIRY=1 runs and logs the waiver; and a build with two days left runs and logs two days left. Two things that only showed up by running it. Negative days first meant "never" rather than "already expired", so the refusal path went untested on the first pass - only 0 means never now. And the days-left count was anchored at midday, reporting one day fewer than the build had; it is anchored at the end of the expiry day, which is the rule the check actually enforces. The packaged README tells testers the build expires, where to get the next one, and that unzipping it over the folder keeps their four files. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
CydandClaude Opus 5
|
a1d2de591c |
The patch number is the commit count
A hand-maintained version says what somebody remembered to type. Pinning it to the repository means a binary always names the commit it came from, so a log from a test machine settles which changes are in it. stamp-version.ps1 runs as RP_L4's pre-build step and writes the generated RP_L4\rpl4build.h: #define RP412_VERSION "4.12.96" #define RP412_VERSION_LONG "4.12.96 (a1b2c3d)" The hash beside the number names the commit exactly; a trailing '+' means the tree had uncommitted changes to TRACKED files when it was built, which is the state a puzzling bug report usually comes from. Untracked files do not count - one scratch document in the tree would otherwise mark every build dirty and the marker would stop meaning anything. Generated rather than committed, and gitignored, because a hardcoded number cannot work: the commit that records "4.12.96" is itself commit 96, so the file is stale the moment it lands. The header is rewritten only when the stamp changes, so ordinary rebuilds do not drag RPL4.CPP through a recompile. pack-dist.ps1 reads that header instead of asking git again - a commit between building and packing would otherwise have the zip claiming a version the binary inside it does not report - and warns when the build it is packing came from a modified tree. The README banner, the zip name and the shipped CONTROLS.html all take the same number. Numbering stays ordered: 95 commits so far, so 4.12.95 follows 4.12.7 and every future build sorts after it. Only the "4.12" line is set by hand, at the top of the script. Two things the wiring turned up: Windows PowerShell turns a native command's stderr into ErrorRecords, so with $ErrorActionPreference = 'Stop' git's routine "LF will be replaced by CRLF" warning threw straight past the dirty check and stamped a modified tree as clean. Every git call now goes through cmd, which keeps stderr out of PowerShell's error stream entirely. The script ended on "git diff --quiet", which exits 1 to mean "there are changes" - as a pre-build step that failed the build on exactly the tree a developer builds in. It exits 0 explicitly now. Verified: deleting the header and building recreates it; a second build reports "(unchanged)" and leaves the timestamp alone; a build on a modified tree succeeds and stamps 4.12.95 (c1729e4+); and the packed game logs "Red Planet 4.12.95 (c1729e4+)" on its first line while README.txt and CONTROLS.html in the same package both read 4.12.95. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |