Generate release notes from GitHub.
Paste a public repository and get release notes built from its merged pull requests, or the commits since the last tag: breaking changes first, then features and fixes, each with its pull request linked.
How it works
A GitHub changelog generator that reads the commits you already write.
No labels to set up, no config file, no account. It uses the same parser as the free GitHub Action, so the notes here are the notes the Action would write.
Finds the range
Since the last version tag by default, so you see your next release. Or any two tags, branches or commits you name.
One entry per pull request
Merge commits, squash merges and rebases all count each pull request once, by its title and number. Chores, CI and tests are left out.
Grouped, breaking changes first
Breaking changes with their migration steps, then Added, Changed, Deprecated, Removed and Fixed, each pull request number linked.
Merged into main · v1.4.0 → v2.0.0
- ●feat(auth)!: make init() return a promise (#212)BREAKING CHANGE: …
- ⑂Add cursor pagination to list endpoints (merge commit, #209)
- ●fix: retry uploads on 429 responses (#207)
- ●chore(deps): bump typescript to 5.9
- ●Deprecate `client.legacyAuth()` in favor of `client.auth()` (#205)
- ●docs: explain retry options
The release notes it writes
⚠️ Breaking changes
- auth: Make init() return a promise (#212)
replace init({ callback }) with await init().
Added
- Add cursor pagination to list endpoints (#209)
Deprecated
- Deprecate
client.legacyAuth()in favor ofclient.auth()(#205)
Fixed
- Retry uploads on 429 responses (#207)
Other changes
- Explain retry options
Full changelog: v1.4.0...v2.0.0
A made-up project. The notes on the right are exactly what the tool writes for the commits on the left; the chore commit is left out.
Free · no LogPulse account
Automate this on every release
The same parser, inside your pipeline: tag a release and its notes are written for you. It runs with your workflow's own token, so private repositories work too.
GitHub Action
Fills in each GitHub release from CHANGELOG.md, or from the merged pull requests since the last tag.
uses: kalmwerk/release-notes-action@v1On GitHub now; Marketplace listing coming soon.
GitLab CI/CD component
The same notes for GitLab releases in a tag pipeline, one entry per merge request. Only needs CI_JOB_TOKEN.
GitLab Catalog listing coming soon.
LogPulse Pro
A draft from every merged pull request, in your product's tone. Approve it and it's on your in-app widget, hosted changelog and subscribers' inboxes.
€12/month or €99/year + VAT.
curl "https://release-ripple-roadmap.lovable.app/api/public/v1/release-notes?repo=honojs/hono&format=markdown"curl "https://release-ripple-roadmap.lovable.app/api/public/v1/release-notes?repo=pnpm/pnpm&from=v10.0.0&to=v10.1.0&format=keep-a-changelog"No key needed. JSON by default, with the notes, the Keep a Changelog section and the release in LogPulse's machine-readable shape. Read the docs.
Questions
Release notes from GitHub, answered
How do I generate release notes from GitHub?
Paste the repository's URL above and press Generate. By default you get everything merged since the last tag: the notes for your next release. To get the notes of a release you've already tagged, open Tag range and set To to that tag; set both ends for any other range. Copy the result into the GitHub release, or into CHANGELOG.md.
Is this a free GitHub changelog generator?
Yes. It turns your merged pull requests and commits into a changelog entry for free, with no account, no token and no AI. Copy the Keep a Changelog version for CHANGELOG.md, or the Markdown for a GitHub release. To have it happen on every release, add the free GitHub Action, which writes these same notes for you.
Which pull requests and commits are included?
Everything in the range, read along the default branch's history. A pull request merged with a merge commit is one entry, by its title and number, and the commits on its branch aren't repeated. A squash-merged pull request is its one commit, and rebased commits are listed once each. Chore, CI, build, test and style commits are left out unless they're breaking, and so are release bookkeeping commits like “Release v1.2.0”.
How are breaking changes, features and fixes grouped?
By Conventional Commits type when commits use it: feat goes under Added, fix under Fixed, perf and refactor under Changed, deprecate under Deprecated. Plain subjects go by their first word (Add, Fix, Remove, Update…). A ! after the type or a BREAKING CHANGE footer marks a breaking change: it comes first, under Breaking changes, with the footer's text as its migration steps.
How is this different from GitHub's “Generate release notes” button?
GitHub's button lists the merged pull requests and new contributors, grouped by labels you configure in .github/release.yml. This tool needs no labels: it reads the commit messages you already write, puts breaking changes and their migration steps first, works for any range, and also gives you a Keep a Changelog section.
Does it work with private repositories?
Not on this page: it reads GitHub without signing in, so it only sees public repositories. The free GitHub Action and GitLab CI/CD component run inside your own pipeline with its token, so they work on private repositories and send nothing to LogPulse.
Is there a limit?
5 lookups a minute and 50 a day per IP address. Repositories looked up recently are answered from a short-lived cache and don't count. Because the page uses GitHub's anonymous API, GitHub can also pause lookups when its hourly allowance runs out; the page says when to try again. A range is read up to its newest 300 commits.
Do you store anything or use AI?
There's no AI: a deterministic parser writes the notes, so the same commits always give the same notes. Results are cached for a few minutes (a few hours for a range that ends at a tag) to spare GitHub's allowance, and nothing is tied to you.
Is there an API?
Yes, with the same limits and no key: GET https://release-ripple-roadmap.lovable.app/api/public/v1/release-notes?repo=owner/repo, optionally with from, to and format=markdown or format=keep-a-changelog.
Notes are only as good as the commit messages behind them. The Conventional Commits guide shows how to write ones that turn into clear release notes.