Question 1

How do I generate release notes from GitHub?

Accepted Answer

Paste the repository's URL above and press Generate release notes. You get the notes for its latest release, written from everything merged since the release before it. To write another release's notes, pick its tag under To; to compare any two releases or tags, pick both. Copy the release notes into the GitHub release and the Keep a Changelog section into CHANGELOG.md.

Question 2

How do I create GitHub releases from existing tags?

Accepted Answer

Choose Backfill releases above and paste the repository. It picks the newest tags that have no GitHub release (back to your latest release), writes each one's notes from the commits since the tag before it, and gives you a script. Run it with the GitHub CLI, signed in with write access: gh release create <tag> --verify-tag --notes-file … publishes each release from its existing tag, oldest first, and skips tags that already have one. Up to 10 tags at a time.

Question 3

Can I pick plain Git tags, not just releases?

Accepted Answer

Yes. Both lists show every tag next to the published releases, labelled “release” or “tag · no release”, and a repository without any GitHub releases uses its tags. A plain tag's notes start at the tag before it; a release's at the release before it, like GitHub's own release notes.

Question 4

Why only 10 tags at a time?

Accepted Answer

This page reads GitHub without signing in, and GitHub allows only a limited number of those requests an hour for everyone together. A backfill reads the commits of its whole run in one go and splits them by tag, so 10 tags usually cost one to three requests. For more, run it again with “Up to” set to the tag the page names: tags already written load from the cache. For a long history or a private repository, run the free GitHub Action by hand with its tag input: it creates the release for an existing tag with your workflow's own token.

Question 5

Will the backfilled releases replace my latest release?

Accepted Answer

No. GitHub makes every newly created release the “Latest” one unless told otherwise, so the script passes --latest=false for the older tags. Only the newest tag of the run becomes Latest, and only when it's newer than your current latest release. Pre-release tags are published as pre-releases.

Question 6

Is this GitHub release notes generator free?

Accepted Answer

Yes: no account, no GitHub token and no AI, for any public repository. It's limited to 5 lookups a minute, 20 an hour and 50 a day per visitor, and releases anyone looked up recently load from a cache without counting.

Question 7

How is it different from GitHub's “Generate release notes” button?

Accepted Answer

GitHub's button lists the merged pull requests and new contributors, grouped by labels you set up in .github/release.yml. This generator needs no labels: it reads the commit messages you already write, puts breaking changes and their migration steps first, groups the rest into features and fixes, and gives you a Keep a Changelog section and plain-language notes for users as well. It also works for releases you've already published and repositories you don't maintain.

Question 8

Which commits and pull requests are included?

Accepted Answer

Everything between the two releases, read along the default branch's history. A pull request merged with a merge commit counts once, by its title and number, and the commits on its branch aren't repeated; a squash-merged pull request is its one commit. Chore, CI, build, test and style commits, merge commits and release bookkeeping like “Release v1.2.0” are left out of the notes, and the Commits tab shows why. A range is read up to its newest 300 commits.

Question 9

How are breaking changes, features and fixes found?

Accepted Answer

From Conventional Commits when the commits use them: feat goes under Added, fix under Fixed, perf and refactor under Changed, deprecate under Deprecated. A ! after the type or a BREAKING CHANGE: footer marks a breaking change; it comes first in the release notes, under “Before you upgrade”, with the footer's text as what to do. Plain subjects are sorted by their first word: Add, Fix, Remove, Deprecate.

Question 10

Who gets thanked?

Accepted Answer

Everyone with a commit between the two releases, by GitHub username, most commits first; bots like Dependabot and Renovate are left out. The first 20 are named and the rest counted. Commits whose email isn't linked to a GitHub account can't be credited.

Question 11

Does it work with private repositories?

Accepted Answer

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, have no anonymous limit and send nothing to LogPulse.

Question 12

What if GitHub's limit is reached?

Accepted Answer

GitHub allows a limited number of anonymous requests an hour. When they run out, the page says when to try again; releases looked up recently still work. To never hit it, let the free GitHub Action write the notes in your own workflow.

Question 13

Is there an API or MCP tool for coding agents?

Accepted Answer

Yes, with the same limits and no key: GET https://release-ripple-roadmap.lovable.app/api/public/v1/github-release-notes?repo=owner/repo, optionally with from and to (releases or tags) and format=markdown or format=keep-a-changelog. Add mode=backfill for every tag in a run, and format=script for the gh script on its own. Coding agents connected to the LogPulse MCP server (https://release-ripple-roadmap.lovable.app/mcp) call the free github_release_notes tool, with mode "backfill" to publish missing releases.

Question 14

Do you store anything or use AI?

Accepted Answer

There's no AI: deterministic rules write the notes, so the same releases always give the same notes. Results are cached for a few minutes (a few hours for two named releases) to spare GitHub's allowance, and nothing is tied to you. We count lookups per day and per page they started from, without the repository name, cookies or IP addresses.

	GitHub's “Generate release notes”	This generator	LogPulse GitHub Action
Reads	GitHub's buttonPull request titles and labels	This generatorCommits and merged pull requests	GitHub ActionCommits and merged pull requests, or CHANGELOG.md
Setup	GitHub's buttonLabels in .github/release.yml	This generatorNone	GitHub ActionOne workflow file
Breaking changes first, with what to do	GitHub's button	This generator	GitHub Action
Keep a Changelog section	GitHub's button	This generator	GitHub Action
Plain-language notes for users	GitHub's button	This generator	GitHub ActionYour CHANGELOG.md's words
Contributors thanked	GitHub's button	This generator	GitHub Action
Any repository, any past release	GitHub's buttonOnly your own, while drafting	This generatorPublic repositories	GitHub ActionYour own, on every tag
Private repositories	GitHub's button	This generator	GitHub Action

GitHub release notes generator.

How to generate release notes from GitHub

Paste the repository

Pick two releases or tags

Check what was left out

Copy and publish

Create GitHub releases from existing tags

Paste the repository and choose Backfill releases

Check the run

Read and copy the notes

Run the script

GitHub's button, this generator, or the Action?

The same notes, one call away.

GitHub release notes, answered