Release Notes and Changelogs
Release notes and changelogs are how software projects tell people what changed between versions. A changelog is the ongoing, curated record in the repository. Release notes are the announcement for one release, drawn from that record and shaped for the people who will upgrade or adopt it.
itTechnical communication and collaboration | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Release Notes and Changelogs
A changelog is the ongoing, curated list of what actually mattered between versions. Release notes are the announcement you hand someone on release day. Same raw material, different jobs. If you only remember one corridor sentence from this course, make it that split.
Before these habits spread, people pointed at git history and called it communication. Git is excellent archaeology. It is a lousy customer newsletter. Commits talk to developers about a unit of work. Changelog entries talk to upgraders about behavior. Mixing them up is how typos get equal billing with breaking API changes, which is how readers learn to ignore you.
Hang the practice on three ideas. First, keep a repository file (usually CHANGELOG.md) as the canonical record: Unreleased at the top, versions with ISO dates, newest first, grouped under Added, Changed, Deprecated, Removed, Fixed, and Security. Second, let the versioning scheme do signaling work (SemVer's major/minor/patch, or CalVer when the calendar is the point) while the prose still names what broke. Third, treat automation as a draft machine: Conventional Commits, labeled PRs, Changesets, release-please, semantic-release, git-cliff. Useful. Not the final editor.
The surprise for many teams is where the work actually lives. Formatting the Markdown is the easy afternoon. Notability is the hard evening. Generators cheerfully assume every commit deserves a bullet and that one commit equals one entry. Multi-commit features and quiet breaks both escape that fantasy. Keep a Changelog's updated advice is almost rude in its clarity: machines can draft, humans curate. Also, do not make CI demand a changelog edit on every pull request unless you enjoy a museum of "wip" lines.
Deprecate before you remove. Mark breaks in place. List yanked releases instead of pretending they never happened. Prefer a file that travels with the repo over notes that only exist in a host database.
Where next: the Intro and Cheatsheet for structure and type rules; Practice and the Exercise when you want to curate a noisy branch into a real section; Field Notes when you need the judgment calls teams regret; Landscape and Reference when you are picking tools. Don't Panic is the map. The other tabs are the terrain.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://keepachangelog.com/en/2.0.0/
Supports
- Changelog definition and purpose
- Changelog versus release notes distinction
- Guiding principles and six change types
- Fixed versus Changed versus Security guidance
- Breaking change marking and Unreleased workflow
- Yanked releases, monorepo layout, and curation over accumulation
- Machines draft and humans curate
- Host release pages versus repository CHANGELOG.md
- CI should not require a changelog edit on every change
- https://semver.org/spec/v2.0.0.html
Supports
- MAJOR.MINOR.PATCH increment rules
- Public API requirement
- Deprecation before removal
- https://semver.org/spec/v1.0.0.html
Supports
- Timeline milestone for SemVer 1.0.0
- https://www.conventionalcommits.org/en/v1.0.0/
Supports
- feat, fix, and BREAKING CHANGE mapping to SemVer
- Commit message structure for automation
- https://calver.org/
Supports
- Date-based versioning schemes and when CalVer fits
- https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes
Supports
- Automatically generated release notes contents
- .github/release.yml categorization
- Review generated notes before publish
- https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository
Supports
- Creating releases, tags, assets, and release bodies
- https://github.blog/changelog/2021-10-20-improvements-to-github-releases-generally-available/
Supports
- Timeline date for auto-generated release notes general availability
- https://developerrelations.com/talks/commit-messages-vs-release-notes-theyre-important-theyre-not-the-same-and-theyre-not-for-you/
Supports
- Commit messages versus release notes audiences
- Do not scrape commits as customer-facing notes
- Field Notes spine card on recycling commits
- https://evaparish.com/speaking
Supports
- Timeline confirmation of the 2019 DevRelCon talk
- https://changesets.dev/guide/getting-started
Supports
- Changeset files as release intent and changelog source
- Monorepo versioning workflow
- https://github.com/googleapis/release-please
Supports
- Conventional Commits–driven release PRs updating CHANGELOG.md
- Timeline creation window for the project
- https://semantic-release.org/
Supports
- Fully automated SemVer, notes, and publish from CI
- https://git-cliff.org/
Supports
- Configurable changelog generation from Conventional Commits
- https://github.com/orhun/git-cliff/releases/tag/v1.0.0
Supports
- Timeline date for git-cliff 1.0.0
- https://keepachangelog.com/en/1.0.0/
Supports
- Timeline milestone for 1.0.0 and early project framing
- https://keepachangelog.com/en/1.1.0/
Supports
- Timeline milestone for 1.1.0
- https://github.com/olivierlacan/keep-a-changelog/blob/main/docs/2.0.0-history.md
Supports
- 2014 project start and verified milestone framing
- https://olivierlacan.com/posts/keep-a-changelog-1-0/
Supports
- Keep a Changelog 1.0.0 release date 2017-06-20
- https://github.com/conventional-commits/conventionalcommits.org/pull/175
Supports
- Timeline window for Conventional Commits 1.0.0
- https://www.npmjs.com/package/conventional-changelog
Supports
- Early automation tooling timeline anchor
- https://docs.gitlab.com/ee/user/project/releases/
Supports
- GitLab Releases placement in the product landscape
- https://changesets.dev/
Supports
- Changesets product URL for Landscape matching
