Switch to semantic versioning, add --version

[refaim]

The binary had no idea what version it was — no --version flag, no version constant anywhere in src/. The release number was invented inside CI from the build date and github.run_number, so it lived only in the git tag and the asset names, and a bug reporter had no way to tell you which build they were on.

The date scheme was also unsound: github.run_number resets when a workflow is recreated, and that already happened here.

2026-01-31  2026.01.31.204
2026-01-31  2026.01.31.3     <- published later, lower number

No ordering comparison can work against that history.

Changes

• src/version.py holds VERSION as the single source of truth.
• pyproject.toml declares dynamic = ["version"] rather than keeping a second copy that drifts — it still said 1.0.
• --version prints snapjaw <VERSION>, and works both with no subcommand (despite subparsers(required=True)) and outside a game directory, since argparse's version action exits during parsing, before gameversion.resolve runs. All three properties are pinned by tests.
• CI reads the version from src/version.py and uses it for the tag, the release name and the asset names.
• CI skips the release when that tag already exists, so a push that does not bump VERSION builds but publishes nothing. Today every push to master cuts a release, including commits that change nothing a user can see — three of the nine existing releases are CI-only changes.

Version number

Existing tags are left alone; rewriting nine published releases would break the /releases/latest redirect and any saved links. The number below is reconstructed only to pick a sane starting point.

existing tag	contents	would have been
2026.01.31.204	52 commits, initial import through the first downloadable build	1.0.0
2026.01.31.3	test suite, Python 3.12, lint and type checking	1.0.1
2026.01.31.5	badges, Codecov	1.0.2
2026.02.14.9	missing addon directories fix (#47)	1.0.3
2026.02.14.11	Linux build	1.1.0
2026.04.25.14	WotLK support, --game-version	1.2.0
2026.08.30.16	clone each repo once, addon naming, stale entries (#52)	1.3.0
2026.08.30.18	GitHub Actions update	1.3.1
2026.08.30.20	empty status table	1.3.2

Hence 1.4.0 for the new flag.

What merging this does

It publishes release 1.4.0. The release job cannot be exercised by PR CI — it is gated on if: github.event_name == 'push' — so the tag lookup and the new naming first run on merge. The lookup uses git ls-remote --exit-code and distinguishes "no such tag" (exit 2) from a genuine failure, so a network or auth problem fails the job rather than silently skipping the release. Bare python is used to read the version and is present on the runner image via python-is-python3.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (f40cd5e) to head (f6a1f6e).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##            master       #56   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            5         6    +1     
  Lines          584       587    +3     
  Branches        98        98           
=========================================
+ Hits           584       587    +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.