How do you automate your release notes?

Question

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&rsquo;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&rsquo;d recommend?If anyone wants to see the script I wrote, I am happy to share it and would love some constructive feedback.

cpburns2009 · Accepted Answer

All I can say is I hate when projects just lazily list every pull request for its change log / release notes. It makes it very difficult to discover what breaking changes there are.

insin · Answer

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.

nitwit005 · Answer

We have our release notes fully automated from git tags, and it's unfortunately useless as people don't actually the right tags on things, so everyone ends up manually editing it.

weinzierl · Answer

Unpopular opinions:1. Release notes should never be created mechanically but focus on the consumer of the release.2. The best changelog is your git. It is OK to generate a calcified changelog for an audience that prefers that.Last and least:3. The commit messages are a private space where developers communicate. The messages should never end up at the customer without thorough filtering and distillation.Apart from that: git-cliff is excellent. If you must generate a document from commits, use that.

effnorwood · Answer

Claude - write some plausible release notes that management will buy but make no actual sense and save it as xml.

richard_obrien · Answer

Full disclosure, I&rsquo;m one of the owners of ReleaseNotes.io. Not trying to pitch, just sharing what we see across a lot of teams.1. For OSS projects, GitHub Releases honestly work really well. You usually have contributors who understand the context, and readers who are technical enough to parse a changelog.2. If you're talking to users, Release notes stop being a dev artifact and become a communication channel. They need to show up where users already are, in-app, email, Slack, etc. There are a bunch of tools like us (ReleaseNotes.io), LaunchNotes, AnnounceKit, Canny and others that help with that.3. From what we see, the teams that have the most success with automation of this process treat GitHub PRs or Jira, Azure DevOps, Linear, GitHub issues as the source of truth. Also their issues/PR descriptions tend to clearly describe the problem and the solution.4. Any automation of this process leans heavily on the quality of your issue/PR descriptions as garbage-in = garbage-out. Because of this it's tricky to fully automate the process as at some level you usually need a person casting an eye over the release note just to sense check.