How to write a changelog developers actually read

Writing a Changelog Developers Read

A changelog is a curated history of changes written for the humans who depend on your software. It is not a git log dump. It is not release notes marketing copy. It answers one question: what changed between versions and does it affect me?

The Keep a Changelog Format

# Changelog

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

## [Unreleased]

### Added
- New `batch()` method for processing up to 100 records in a single request

## [2.1.0] - 2024-06-01

### Changed
- `getUserById()` now returns `null` instead of throwing `NotFoundError` when user does not exist

### Deprecated
- `getUser()` is deprecated. Use `getUserById()` instead. Will be removed in v3.0.

### Fixed
- Fixed memory leak in connection pool when connections were not explicitly closed

## [2.0.0] - 2024-04-15

### Removed
- Removed `legacyAuth()` (deprecated since v1.5.0)

What Makes a Good Entry

Each entry must tell the developer: what changed, and whether they need to do anything about it. "Fixed a bug" is useless. "Fixed memory leak in connection pool when connections were not explicitly closed" tells a developer exactly whether this affects their code.