200apps Corpus

Appearance

Release & Communication · master area

Changelog Generation ​

Auto-built from conventional commits. The changelog writes itself when commit messages do their job — and reading the auto-generated draft against the release brief is the chain's last cross-check before client communication.

Owners: Pipeline Owner, Tech Lead, PO Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: Every artifact in the chain is a hedge against the departure of the person who created it.

Where it lives in the chain ​

How to do this ​

  • Auto-generate from conventional commits between two tags. feat: and fix: and perf: surface; chore:, refactor:, test:, docs: are typically suppressed in the user-facing changelog.
  • Group by scope — grading, auth, billing. The client reads by domain, not chronologically.
  • Review before publication — the PO reads the draft against the release brief. If a commit's description isn't readable by the client, the description gets a one-line rewrite — in the changelog, not in git history.
  • Link to issues — [GR-204] references stay; they become anchors at the support helpdesk.

What good output looks like ​

markdown
## 2026-05-18

### Grading
- Submit shortcut returns to next exam. (GR-204)
- Fix: negative balances display correctly in red. (GR-211)

### Auth
- Tokens now refreshable in the background; users no longer see surprise logouts. (AU-118)

### Performance
- Grading session load time improved 40% under heavy use. (GR-220)

A team without conventional commits writes the changelog by hand at release time, from memory and git log --oneline. It takes 30 minutes, gets things wrong, and the client receives a release note that says "various improvements." A team with conventional commits writes the changelog in 5 minutes of review. The discipline pays back every release.

200apps · How We Work · NWIRE

Internal corpus. Voice and structure © 200apps.