whats-new drafts from player-facing notes first (whatsNew.source, docs/RELEASE-<version>.md, the CHANGELOG section of the version or Unreleased; --release, --from-git) and only then from the git log; internal jargon warnings (SDK / vendor names, developer and version-control words, file paths, issue ids, code identifiers) with plain alternatives in the draft and whats-new check, one list in cli/lib/jargon.ts, whatsNew.allowWords keeps a word; skill: write from what players feel, never from commit messages; tests
This commit is contained in:
parent
e9507d8884
commit
bab3f63227
9 changed files with 287 additions and 21 deletions
|
|
@ -5,12 +5,30 @@ description: Write user-facing release notes ("What's new") for a mobile app or
|
|||
|
||||
# What's new (release notes)
|
||||
|
||||
CLI: `storebound whats-new [--since v1.2.0] [--dry]`. It reads `git log <tag>..HEAD`, drops housekeeping commits
|
||||
CLI: `storebound whats-new [--since v1.2.0] [--release 1.2.0] [--dry]`. It takes a player-facing source when one exists (below); otherwise it reads `git log <tag>..HEAD`, drops housekeeping commits
|
||||
(chore, ci, docs, refactor, test, merges, version bumps), turns `feat:` / `fix:` / `perf:` subjects into bullets and
|
||||
writes a draft into the default language of `store/listing.md` (Play "What's new") and `store/appstore.md`
|
||||
(`whatsNew`). Nothing is sent to a store. `--all` writes the draft into every language as a starting point for
|
||||
translation; `storebound check` warns while a translation is still identical to the source.
|
||||
|
||||
## Where the text comes from
|
||||
Write from what players feel, never from commit messages. Commit subjects are written for developers ("Umami
|
||||
telemetry", "refactor save endpoint", SDK and tool names); players care about what they see and feel ("Levels load
|
||||
faster", "Your progress is saved more reliably"). So the draft comes from a player-facing source first, the first
|
||||
that exists:
|
||||
1. `whatsNew.source` in the config (a notes file; a CHANGELOG-like file gives the version's `## <version>` section),
|
||||
2. `docs/RELEASE-<version>.md`,
|
||||
3. the `CHANGELOG.md` section of the version, else its `## Unreleased` section.
|
||||
The version is `--release 1.2.0`, else `package.json`. Only without any of these (or with `--from-git`) the draft is
|
||||
built from `git log`; treat that draft as raw material and rewrite every line. If a project keeps a developer
|
||||
changelog, add a short player-facing `docs/RELEASE-<version>.md` instead of reusing commit-speak.
|
||||
|
||||
The draft and `whats-new check` warn about internal jargon (never blocking): SDK / vendor names (Umami, Sentry,
|
||||
Firebase, Capacitor, Tauri, Jenkins, Forgejo, ...), developer words (telemetry, refactor, endpoint, payload, API,
|
||||
CI, PR, OTA, fingerprint, bump, deps, ...), version-control words (commit, merge, revert), file paths, issue ids and
|
||||
code identifiers (`saveSlot`, `max_lives`). Each warning names the word and a plain alternative. Rewrite the line;
|
||||
when a flagged word is a real player-facing term (a character called "Sentry"), add it to `whatsNew.allowWords`.
|
||||
|
||||
## Write it for your users
|
||||
1. Run `storebound whats-new --dry`, read the draft with the owner.
|
||||
2. Rewrite:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue