GitHub Releases is the free, tag-based release page every repository already has: click "Generate release notes" and GitHub rolls up the merged pull-request titles since the last tag for the people who have a GitHub account and watch your repo. A changelog tool is the readable record of what shipped — a changelog page on your own domain, an embed in your product, an email list and an RSS feed — for the users who do not live on GitHub. The honest rule: a library, CLI or API with a developer audience rarely needs more than Releases; a product with users does.
Looking for the product answer? Shipstar is a changelog management tool with an AI generator built in — that page has the tool comparison, integrations, and pricing. This post is the deep dive on what GitHub Releases does and doesn't cover.
What is a changelog tool?
A changelog tool is the hosted, readable record of what shipped plus the distribution around it: a changelog page on your own domain, an embed inside the product, email subscribers and an RSS feed, and a way to produce the entries — written by hand, or drafted from the repository's commits and pull requests for a person to review before anything goes out. The two camps that exist today, write-it-yourself suites and generate-from-git pipelines, are laid out below.
Two things that are often called changelog tools are not one in this sense. A CHANGELOG.md generator — git-cliff, conventional-changelog, github-changelog-generator — writes the file for people who already have the code. GitHub Releases is the per-tag record on github.com. Both are free, which is the baseline the rest of this post measures against; if "free changelog tool" is the search, those two are the answer, and among hosted tools free tiers exist too — Shipstar's Free plan is $0 with 1,000 credits a month, and a changelog costs 100.
What do GitHub releases do?
Every GitHub repository ships with a solid release baseline. Tag a version, click "Generate release notes," and GitHub produces a release page with the merged pull requests since your last release, grouped into sections you configure with labels in .github/release.yml, plus a contributor list and a full-changelog compare link.
Around that you get watcher notifications, an Atom feed at releases.atom, unlimited release assets with no bandwidth charges, and a complete REST API — including programmatic note generation. Free, on every plan, already in your workflow.
Are GitHub releases public?
Releases follow the repository's visibility: GitHub's docs put it as "anyone with read access to a repository can view and compare releases," so on a public repository that is everyone, and on a private repository it is only the people who already have access. Notifications are opt-in on top of that — a person can subscribe to a repository's releases alone, without the rest of its activity. That is the audience limit the next sections are about: a release being reachable on github.com is not the same as your users being told about it.
What "Generate Release Notes" Actually Produces
The auto-generated notes are a mechanical roll-up of merged PR titles — deterministic, not AI. If the PR was titled "fix flaky retry test in CI," that is your release note, verbatim. For a developer audience that reads PR titles fluently, that's fine. For users, it's noise: internal jargon, refactors mixed with features, and nothing explaining why anyone should care.
What is a changelog in GitHub?
On GitHub the word covers three different things. The first is a CHANGELOG.md file in the repository root — the Keep a Changelog convention: one section per version, newest first, changes grouped under Added, Changed, Fixed and Removed, with an Unreleased section at the top. It travels with the code and is read by people who already have the code.
The second is the Releases tab: GitHub's own per-tag record, with the generated notes described above and any attached binaries. Many projects maintain both and point one at the other.
The third is a hosted changelog page outside the repository, written for users rather than contributors. The file generators — github-changelog-generator, git-cliff, conventional-changelog — build the first kind from commit prefixes or pull-request labels in CI, and they are the right tool when the file is the deliverable. If you want to generate a changelog from GitHub commits that reads like product writing and lives on your own domain, that is the third kind, and it is what the rest of this post is about.
What is the difference between a release note and a changelog?
A changelog is the running public record of what shipped, period by period, in one place. Release notes are the announcement for a single release — the email, post or release page that tells users what is in version 2.4 and why it matters. GitHub Releases is release notes per tag, which is why it feels like both: it accumulates into a history, but each entry is written for one release. In practice a product needs the record and the announcement; the formats are in our changelog examples and template and release notes examples and template.
Where the Baseline Stops
- Your audience must live on GitHub. Release notifications only reach people with GitHub accounts who watch your repo's releases. There is no way to collect email addresses from regular users.
- No home for the changelog. Releases live under
github.comnext to your code — there's no branded changelog page on your domain, no in-app widget, no embed. - No distribution. No email list, no Slack publishing, no social posts. Every channel beyond the repo is a custom Action you build and maintain.
- No analytics. Beyond asset download counts, you can't tell whether anyone read a release.
- The writing problem remains. PR-title roll-ups aren't user-facing writing, and GitHub's AI option (the copilot-release-notes Action) is a separate self-assembled workflow that requires a paid Copilot seat.
| GitHub Releases | CHANGELOG.md file | Hosted changelog tool | |
|---|---|---|---|
| Who can read it | Anyone on github.com; notifications only reach watchers with GitHub accounts | Anyone with the repository | Anyone with the link — your users |
| Where it lives | The repository's Releases tab | In the repository, next to the code | A page on your domain, plus an embed in your product |
| How people hear about it | Release notifications and the releases Atom feed | They don't, unless they read the repo | Email subscribers, RSS, the embed |
| Email list | No | No | Yes |
| Who writes the text | Generated from merged pull-request titles, or you | You, or a generator parsing commit prefixes | You, or an AI draft from the commits that you review |
| Cost | Free, included with every repository | Free | Free tiers exist; paid plans vary by vendor |
GitHub Releases column and the visibility note above checked against GitHub's docs on about releases, automatically generated release notes and managing releases, October 2026.
When GitHub Releases Is Enough
Honestly: often. Stay with the baseline if your project is a library, CLI, or API whose entire audience is developers with GitHub accounts; if PR titles are genuinely readable release notes in your repo; and if you don't need to reach anyone by email, in-app, or on social. Open-source maintainers rarely need more.
When a Changelog Tool Earns Its Keep
The case for a dedicated tool starts the day your users stop being your contributors — a SaaS dashboard, a paid product, anyone who would never think to watch a repo. Then you need a changelog page they can find, an email list they can join, a widget inside the product, and release notes written for readers rather than reviewers.
Changelog tools split into two camps:
- Write-it-yourself communication suites — AnnounceKit, Beamer, LaunchNotes. Excellent widgets, segmentation, feedback boards, and email delivery, but a person still writes every update.
- Generate-from-git pipelines — ChangelogAI, Herald, and Shipstar. These read your actual development activity and draft the content, so the changelog keeps itself current.
You Don't Have to Choose
The pragmatic setup keeps GitHub Releases for your developer audience and layers a tool on top for everyone else. Shipstar reads the same raw material — your commits and merged PRs — and drafts automated changelogs, release notes emails, Slack updates and social posts from it. Each is its own draft that you review and approve; the changelog publishes to a hosted changelog page, the embeddable widget, RSS and your changelog email subscribers. The free plan — $0, 1,000 credits a month, with a changelog costing 100 credits — means the baseline-cost argument disappears, and Solo is $25/month or $240/year when you outgrow it.
See the full Shipstar vs GitHub Releases comparison, or connect a repo free and compare the generated changelog against your PR titles.