Markdown Changelog Template

Based on the Keep a Changelog standard. Track every release with sections for additions, changes, fixes, and removals.

# Changelog

All notable changes to this project will be documented in this file.

## [1.0.0] - YYYY-MM-DD

### Added

- New feature one
- New feature two

### Changed

- Updated dependency from v1 to v2
- Improved performance of X

### Fixed

- Bug where X caused Y
- Typo in documentation

### Removed

- Deprecated API endpoint /v1/old

## [0.2.0] - YYYY-MM-DD

### Added

- Initial public release
- Core functionality

Open Editor and Paste →

Changelog Best Practices

The Keep a Changelog convention is widely adopted in open source. Each release gets a heading with the version number and date. Changes are grouped into Added, Changed, Fixed, and Removed.

Write for humans, not machines. Each entry should be a short sentence that a user can understand. "Fixed a race condition in the connection pool" tells someone what was fixed — not just "Bug fixes."

Semantic versioning helps. Major version bumps (1.0.0 → 2.0.0) indicate breaking changes. Minor bumps (1.0.0 → 1.1.0) mean new features. Patches (1.0.0 → 1.0.1) are for bug fixes.

Markdown Changelog Template

Changelog Best Practices

Related Documentation Templates