mirror of
https://github.com/jmelovich/Steam-Link-PS5.git
synced 2026-10-22 03:42:41 -05:00
jmelovich
61f23e44cd
My previous commit had CI stamp contentVersion into the artifact at build time and deliberately leave the committed sce_sys/param.json at a baseline. Reading ps5-homebrew-catalog's docs/versioning.md shows that is the one thing that does not work. Rule 4 there is "keep param.json in your repository, with the value the release actually ships, in the commit your release tag points at", and the submission check searches the repository *at the release tag* for it. A console finds updates by comparing its installed contentVersion with the catalog's content_version, which is read from that committed file - not from the ZIP. So stamping only the artifact would have listed every release with contentVersion 01.000.000 and produced the documented failure "contentVersion is still 01.000.000: listed, but consoles won't see it as an update". Exactly the outcome the stamping was meant to prevent. Invert it. tools/release.sh bumps contentVersion, commits that, then tags, which is the order docs/versioning.md's own release checklist gives. It refuses a dirty tree, a detached HEAD, an existing tag and a version that is not actually a bump, because each of those produces a tag that cannot be reproduced or a release consoles ignore. tools/set-content-version.sh grows a --check mode that verifies without writing, and CI now runs that on a tag instead of stamping: if the committed value and the tag disagree the release fails loudly, naming the command to fix it, rather than publishing something subtly inert. Tested: --check passes on a match, exits non-zero on a mismatch and writes nothing; release.sh refuses a dirty tree and a duplicate tag, and on a clean tree produces the bump commit plus the annotated tag. make test: 13 tests pass.