Markdown for Changelog Writing - Keep a Changelog Guide
Learn to write changelogs in markdown following Keep a Changelog standard. Document version history, breaking changes, and migration guides with best practices.
Markdown for Changelog Writing
A changelog documents version history, breaking changes, and new features. Write changelogs in markdown following Keep a Changelog standard to help users understand what changed, what's new, and how to migrate between versions.
Quick answer: Follow Keep a Changelog format: group changes by version (newest first), then by type (Added, Changed, Deprecated, Removed, Fixed, Security). Use semantic versioning (1.2.3) and include migration guides for breaking changes.
Why Changelogs Matter
Benefits for Users
- Upgrade decisions: Understand what changed before upgrading
- Migration planning: Know if breaking changes affect you
- Feature discovery: Learn about new capabilities
- Bug verification: Confirm your issues are fixed
- Security awareness: Stay informed about security updates
Statistics: 85% of developers check changelogs before upgrading dependencies (2025 developer survey).
Benefits for Maintainers
- Release history: Track all changes over time
- Communication: Clear, structured release notes
- Version control: Git-friendly plain text format
- Automation: Easy to generate from git commits
- Reference: Historical record of decisions and changes
Keep a Changelog Format
Standard Structure
Version Format
Semantic Versioning
Version Format
Examples
Change Types Explained
Added
New features added to the project.
Changed
Existing functionality changed in a backward-compatible manner.
Deprecated
Existing features marked for future removal.
Removed
Features removed in this release (always breaking).
Fixed
Bug fixes that don't add new functionality.
Security
Security-related fixes and updates.
Complete Changelog Example
Migration Guides
Breaking Change Migration
v2.0:
Migration: Update all API endpoint URLs to include /v2 prefix.
Authentication Changes
v1.x:
v2.0:
Migration:
- Get your new API token from
- Update authentication to use
Authorization: Bearer YOUR_TOKENheader - Remove API key from query parameters
Response Format Changes
v1.x Response:
v2.0 Response:
Migration: Update response parsing to use data array and handle new meta object.
Code Migration Examples
JavaScript (v1.x):
JavaScript (v2.0):
Python (v1.x):
Python (v2.0):
Deprecation Notices
The following features are deprecated and will be removed in v3.0.0:
- Old API endpoint
/api/v1/users(use/api/v2/users) --legacy-modecommand-line flagget_user_data()function (usegetUser())
Replace these features with their v2.0 equivalents before upgrading to v3.0.0.
- Upgrade to Node.js 18+:
- Test your application with new version
- Update deployment configuration
Why: Node.js 14 and 16 are end-of-life and no longer receive security updates.
2. Legacy get_user_data() Function
Impact: Replace get_user_data() with getUser().
v1.3.x Usage:
v1.4.0 Migration:
Migration Steps:
- Find all usages of
get_user_data() - Replace with
await getUser() - Update calling functions to be async
- Test thoroughly
Why: getUser() provides better error handling and TypeScript support.
3. Legacy OAuth Provider Support
Impact: Legacy OAuth providers (OAuth 1.0a) no longer supported.
v1.3.x Providers:
- Google (OAuth 1.0a)
- Facebook (OAuth 1.0a)
- Twitter (OAuth 1.0a)
v1.4.0 Providers:
- Google (OAuth 2.0)
- GitHub (OAuth 2.0)
- GitLab (OAuth 2.0)
Migration:
- Update OAuth provider to OAuth 2.0
- Update client credentials in
- Update authentication flow to use OAuth 2.0
- Test new OAuth flow
Why: OAuth 1.0a is deprecated and insecure. OAuth 2.0 provides better security and features.
2. Use Semantic Versioning
3. Group by Type
4. Link to Issues/PRs
5. Include Migration Guides for Breaking Changes
6. Add Release Dates
7. Use Unreleased for Planned Changes
8. Keep Security Issues Prominent
Automation and Tools
Generating Changelogs from Git
Changelog Generation Tools
- conventional-changelog: Generates changelogs from conventional commits
- lerna-changelog: Monorepo changelog generator
- semantic-release: Automated versioning and changelog generation
- github-changelog-generator: Creates changelogs from GitHub releases
CI/CD Integration
FAQ
How often should I update the changelog?
Update with every release. Add items to "Unreleased" section as you work, then move to version section on release.
Should I include every bug fix?
Include bug fixes that affect users. Internal refactors or minor fixes not visible to users can be omitted or grouped.
What if I forget to add something to the changelog?
Don't retroactively add to released versions. Add to current Unreleased section or document in next release. Historical accuracy matters.
Should I include unreleased features in the changelog?
Yes, use "Unreleased" section to show what's planned or in development. Remove or move to version on release.
How detailed should migration guides be?
Provide step-by-step instructions with code examples. Include before/after code, clear explanations, and test recommendations.
Summary
Changelog Structure:
- Introduction and format description
- Unreleased section
- Version sections (newest first)
- Each version: Added, Changed, Deprecated, Removed, Fixed, Security
- Migration guides for breaking changes
- Links to issues and PRs
Change Types:
- Added: New features
- Changed: Backward-compatible changes
- Deprecated: Features to be removed
- Removed: Features removed (breaking)
- Fixed: Bug fixes
- Security: Security fixes
Best Practices:
- Follow Keep a Changelog format
- Use semantic versioning (MAJOR.MINOR.PATCH)
- Keep entries concise
- Link to issues/PRs for context
- Include migration guides for breaking changes
- Update with every release
- Keep security issues prominent
Common Mistakes:
- Missing migration guides for breaking changes
- Using unclear version numbers
- Writing verbose, wordy entries
- Not marking breaking changes clearly
- Forgetting to update after releases
— Free Monaco-powered editor with live preview and GFM support.
Data sources: Keep a Changelog specification, Semantic Versioning standard, industry changelog best practices (2025-2026).
Practice
Try it in the editor.
Open Markdown Visualizer and test the ideas from this article in a live editor with instant preview.