Keep a CHANGELOG

Don’t let your friends dump git logs into CHANGELOGs™

What’s a change log?

A change log is a file which contains a curated, chronologically ordered list of notable changes for each version of an open source project.

What’s the point of a change log?

To make it easier for users and contributors to see precisely what notable changes have been made between each release (or version) of the project.

Why should I care?

Because software tools are for people. If you don’t care, why are you contributing to open source? Surely, there must be a kernel (ha!) of care somewhere in that lovely little brain of yours.

I talked with Adam Stacoviak and Jerod Santo on The Changelog (fitting, right?) podcast about why open source maintainers and contributors should care, and the motivations behind this project. If you can spare the time (1:06), it’s a good listen.

What makes a good change log?

I’m glad you asked.

A good change log sticks to these principles:

How can I minimize the effort required?

Always have an "Unreleased" section at the top for keeping track of any changes.

This serves two purposes:

What makes unicorns cry?

Alright…let’s get into it.

There’s more. Help me collect those unicorn tears by opening an issue or a pull request.

Is there a standard change log format?

Sadly, no. But I want to change that.

This project contains what I hope will become the standard CHANGELOG file for all open source projects. Take a look at it, and please suggest improvements!

What should the change log file be named?

Well, if you can’t tell from the example above, CHANGELOG.md is the best convention so far.

Some projects also use HISTORY.txt, HISTORY.md, History.md, NEWS.txt, NEWS.md, News.txt, RELEASES.txt, RELEASE.md, releases.md, etc.

It’s a mess. All these names only makes it harder for people to find it.

Why can’t people just use a git log diff?

Because log diffs are full of noise. Can we really expect every single commit in an open source project to be meaningful and self-explanatory? That seems like a pipe dream.

Can change logs be automatically parsed?

It’s difficult, because people follow wildly different formats and file names.

Vandamme is a Ruby gem created by the Gemnasium team and which parses many (but not all) open source project change logs.

Why do you alternate between spelling it "CHANGELOG" and "change log"?

"CHANGELOG" is the name of the file itself. It's a bit shouty but it's a historical convention followed by many open source project. Other examples of similar files include README, LICENSE, and CONTRIBUTING.

The uppercase naming (which in old operating systems made these files stick to the top) is used to draw attention to them. Since they're important metadata about the project, they could be useful to anyone intending to use or contribute to it, much like open source project badges.

When I refer to a "change log", I'm talking about the function of this file: to log changes.

What about yanked releases?

Yanked releases are versions that had to be pulled because of a serious bug or security issue. Often these versions don't even appear in change logs. They should. This is how you should display them:

## 0.0.5 - 2014-12-13 [YANKED]

The [YANKED] tag is loud for a reason. It's important for people to notice it. Since it's surrounded by brackets it's also easier to parse programmatically.

How can I contribute?

This document is not the truth; it’s my carefully considered opinion, along with information and examples I gathered. Although I provide an actual CHANGELOG on the GitHub repo, I have purposefully not created a proper release or clear list of rules to follow (as SemVer.org does, for instance).

This is because I want our community to reach a consensus. I believe the discussion is as important as the end result.

So please pitch in.