A public changelog does more work than it looks. It shows the project is maintained, it re-engages people who tried it months ago, and it's a low-effort reason to appear in front of your users regularly.

1. Write for users, not for git

The mistake is dumping commit messages. Nobody outside your head cares that you "refactored the export handler".

Every entry answers: what can I do now that I couldn't before, or what stopped being annoying? If an entry doesn't have an answer, it doesn't belong in the changelog.

changelog-entry.txt
Here are my commits since the last release: <paste git log>

Write changelog entries for users, not developers. Rules:
- Group as Added, Improved, Fixed. Skip empty groups.
- Each entry says what the user can now do, or what stopped being
  annoying. Not what code changed.
- Plain language. No internal names for things users see differently.
- Omit anything with no user-visible effect.

Then tell me which changes are worth mentioning to existing users
directly, and which are just housekeeping.

2. Keep it as files

Markdown files, one per release, with a date. Same pattern as a blog. No database, easy to edit, and the history lives in your repo.

3. Give it a feed

RSS, and an email option if you have addresses. This is where the re-engagement value is: someone who signed up in March and drifted away gets a reason to come back when the thing they wanted appears.

4. Show the recent one in the app

A small "what's new" indicator, dismissible, that links to the full changelog. It reaches the people who'll never visit the page directly.

Don't make it a modal that interrupts what someone was doing.

5. Ship on a rhythm

A changelog with a six-month gap says the opposite of what you wanted. Even small entries are worth publishing — regular small updates read as momentum, and momentum is most of what a changelog communicates.

Link each entry to the person who asked for it, where you can. "Requested by several of you" turns a release note into a reason to send feedback.