tim.mccarthy/pirats
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Batch testing changes and document explicit release workflow

Browse Source
This commit is contained in:
tim.mccarthy
2026-09-04 20:28:52 -07:00
parent c4f5980fbb
commit 6e5d57e4fc
4 changed files with 33 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+9 -3
View File
@@ -42,9 +42,15 @@ When you run into a repeatable problem during testing (e.g. port assignment coll
The app shows its version number and a player-facing changelog in the ☰ menu → About. Both come from `frontend/src/lib/changelog.js` (rendered by `frontend/src/components/AboutModal.svelte`).
- Bump `VERSION` by one on **every** commit.
- When a commit changes something players can see, add an entry to the **top** of `CHANGELOG` (`{ version, date, changes: [...] }`) describing it in player-facing terms. Group everything shipping under one version into a single entry.
- The changelog is for players: skip refactors, tests, tooling, and other internal-only changes. A commit with no user-facing change bumps `VERSION` but adds no entry.
- Ordinary commits do **not** bump `VERSION` or the Nix package versions.
- Accumulate player-visible changes in one entry at the **top** of `CHANGELOG` with `version: null` and `changes: [...]`. The About dialog labels it **In testing**. Append to or consolidate this batch across commits; do not create a separate entry per commit or assign a release date yet.
- The changelog is for players: skip refactors, tests, tooling, and other internal-only changes. Internal-only commits need no changelog entry.
- Release labeling is a separate process, performed only when explicitly requested. At release time:
1. Consolidate the In testing batch into meaningful player-facing groups using `groups: [{ title, changes: [...] }]`, replacing its flat `changes` list. Remove duplicates and describe the final behavior.
2. Bump `VERSION` by one and give the batch that numeric `version` plus the release `date` (`YYYY-MM-DD`).
3. Bump **both** package `version` values in `flake.nix` (`pirats-frontend` and `pirats`) to the same new Nix release version. Preserve the Nix version scheme; do not equate its semantic version with the app's integer V number.
4. Commit the release metadata together. The next player-visible development change starts a fresh In testing entry.
- Preserve already numbered history unless the user explicitly requests reorganizing past releases.
## Work order