This page

A changelog, at /changelog and linked from the footer. Every release and, between them, the changes worth naming — read from one typed list and rendered by the converter the product sells.

A changelog is only useful if you can trust what is not in it, so this says what gets an entry.

What does

Anything a person using TransformPipe would notice: a conversion that did not exist before, a new page, another way to sign in, a limit that moved, a bug that was visibly wrong. A tagged release carries its version number; most of what has shipped went out between tags and carries none, which is why the list is longer than the list of releases.

What does not

Refactors, dependency bumps, build and infrastructure work — anything invisible from outside. The note at the top of the page says so, which is the reason to keep it true: an entry about a moved file would make that note a lie, and a changelog you have to filter is one you stop reading.

One list, several places

Every entry comes off a single typed list in the repository. The page, the five prerendered languages, the lastmod in the sitemap and the handful of entries with pages of their own all read it — there is no second file to keep in step and none to forget. The bodies are Markdown, rendered by the product's own converter: a release note that breaks the renderer would break a customer's document too, and this is a better place to find that out.

English, deliberately

The chrome is translated — the heading, the lede, the panel, and the dates and month names, which Intl renders in your language. The entries themselves are not. Five translations per entry, per release, forever is a cost that gets skipped after the second release, and a changelog with three languages missing is worse than one that is honestly English. Where an entry has earned a page of its own, that page can be translated, because there are a handful of those rather than one per release.

Related: release notes from Markdown, and documentation that lives in the repo.