A changelog is a record of what changed in a piece of software, written for the people who use and maintain it. The Keep a Changelog convention defines it plainly: “A changelog is a file which contains a curated, chronologically ordered list of notable changes for each version of a project.” Its first guiding principle is that “Changelogs are for humans, not machines.”
The practice has deep roots in the GNU tradition of the ChangeLog file. The GNU coding standards instruct developers to “Keep a change log to describe all the changes made to program source files,” explaining that “the purpose of this is so that people investigating bugs in the future will know about the changes that might have introduced the bug.” A change log, the standards add, can also “help you eliminate conceptual inconsistencies between different parts of a program” by recording how and why decisions were made.
The two traditions differ in audience. The classic GNU ChangeLog is fine-grained software forensics aimed at maintainers, close to what a version-control log now provides automatically. Keep a Changelog instead targets users and integrators, grouping notable changes per release under categories such as Added, Changed, Deprecated, Removed, Fixed, and Security, with the latest version first and each release dated.
The GNU standards acknowledge the shift, noting that version-control systems can now serve as the primary change record, with traditional ChangeLog files generated from VCS history when needed. The enduring idea across both is the same: a deliberate, readable summary of what changed and why, distinct from the raw commit history a tool produces.