Free template
Changelog template (Keep a Changelog)
Copy-paste Markdown for CHANGELOG.md — Unreleased section, semantic versions, and the standard change types. Then publish a customer-facing feed with Feedif when you outgrow a file in the repo.
Free template
Copy-paste Markdown for CHANGELOG.md — Unreleased section, semantic versions, and the standard change types. Then publish a customer-facing feed with Feedif when you outgrow a file in the repo.
# Changelog All notable changes to this project are documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/), and this project adheres to [Semantic Versioning](https://semver.org/). ## [Unreleased] ### Added - ### Changed - ### Deprecated - ### Removed - ### Fixed - ### Security - ## [1.0.0] — YYYY-MM-DD ### Added - Initial public release notes for customers (not an internal dump of commits) ### Fixed -
Replace “fix NPE in FooService” with what the user experienced and what’s better now.
Added / Changed / Fixed / Security scans faster than a flat bullet list of 40 commits.
Use the ship date customers care about. Link a build SHA in docs if engineers need it.
Put migrations under Changed with bold “Breaking” so nobody misses them.
If someone requested the feature, tell them — email or in-app toast beats a silent markdown file.
A CHANGELOG.md is perfect for contributors. Customers need a URL, an in-app toast, and email when their request ships. Feedif is that layer — 7-day trial, then $15/mo.
A community convention for CHANGELOG.md: versioned sections with Added, Changed, Deprecated, Removed, Fixed, and Security. It’s readable for humans and easy to diff in git.
Yes — copy-paste freely. When you’re ready to publish for customers (not only git), Feedif adds a public feed, in-app toast, and voter email.
Same job for most SaaS teams. “Format” is structure; “release notes” is the customer-facing copy inside each version.
Use the free release notes generator: paste commits, get grouped Markdown, then edit for customers.