|
Full disclosure, I’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. |
+1 for highlighting that PR quality is the bottleneck. Garbage-in/garbage-out is exactly what I ran into and it’s why I’m planning to introduce PR templates so the why/what changed/impact is consistently present. For sparse PR bodies, I also optionally add truncated diff context for the LLM summary so the output isn’t just a long list of raw PR titles.
Also agree there is a split between dev-facing changelogs vs user-facing release comms that need to land where users are. What I built is aimed at the "developer-consumer" audience, people using the library, not contributing to it: it renders into our docs and is meant to be readable as a curated changelog, not a raw list of commits.