Ask HN: How do you automate your release notes?

How are you generating release notes in your projects?

I just had to backfill a year of docs release notes for an OSS repo. I ended up writing a small release tag driven generator: it walks git tags, collects merged PRs between releases, buckets them into categories, and renders Markdown/MDX grouped by year -> month -> category -> version. I also added an optional LLM step that outputs structured JSON via Pydantic schema for PR bullets that includes monthly summaries. It is idempotent and preserves manual edits or omissions, so you can auto-generate, then curate over time.

I’m curious what works for you in practice:

- Towncrier?

- reno?

- GitHub Releases / auto-generated notes?

- something else?

What do you like/hate about your current setup? Any tools you’d recommend?

If anyone wants to see the script I wrote, I am happy to share it and would love some constructive feedback.

That has been my concern as well. The script I wrote tries to bucket entries into categories, including "Backward Incompatible Change" so those are easier to spot. Since it is automated I am trading some accuracy for time saved, which seemed like the only practical choice for me, since I had to backfill a lot of history, but it’s been surprisingly decent so far.

I am also planning to add some PR templates so contributors include the context up front, which should make any release note generation more accurate.

Are you using any tooling to help with changelog curration? I know towncrier is all about fragments, so contributors must had write a brief summary of their contribution, which would be more in-line with your preference.

I add release notes to a draft Markdown file in the same commit as every change, under the appropriate Breaking / Changes etc. heading, so when I'm ready to release that becomes the next release notes.

I've never seen an auto-generated set of release notes I liked, a list of PRs doesn't cut it.

+1 on separating "how to upgrade" due to breaking changes from "what’s new". A dedicated BREAKING.md / MIGRATIONS.md is a really good idea.

One thing I am trying to do is make the generator surface breaking/migration items explicitly, but I still think anything that requires human judgment (migration steps, caveats) should be hand-curated in a dedicated document like you suggested.

Yeah, that matches what I have seen: if the upstream metadata isn’t reliable, automation can amplify the mess.

I tried to avoid relying solely on contributors to accurately label or tag things correctly. The script is tag-driven only for release boundaries (version tags), while categorization is derived from PR title & body with optional GitHub metadata. The script is idempotent and preserves edits/omissions so you can correct the few bad ones post-generation.

If you are curious, I am happy to share my script and would be genuinely interested whether it reduces the manual cleanup for your workflow. Also, if you run it with `--ai --github` and a PR body is sparse, it fetches a truncated PR diff and uses that as extra context for the LLM summary.