Keep a Changelog ist Olivier Lacans auf keepachangelog.com veröffentlichte Konvention für eine von Menschen kuratierte CHANGELOG.md, die auf dem Grundsatz beruht, dass Changelogs für Menschen da sind, nicht für Maschinen. Einträge stehen unter sechs festen Änderungstypen, Added, Changed, Deprecated, Removed, Fixed und Security, mit der neuesten Version zuerst, Daten im Format YYYY-MM-DD und einem Unreleased-Abschnitt ganz oben. Commit-Log-Abzüge lehnt sie ausdrücklich ab: Maschinen dürfen entwerfen, aber Menschen kuratieren.

Keep a Changelog

Details

Vollständiger Name: Keep a Changelog, die Changelog-Konvention von keepachangelog.com
Auch bekannt als: die CHANGELOG.md-Konvention, keepachangelog-Format, das Added/Changed/Fixed-Format

Kernkonzepte:

Der Leser ist ein Mensch: Das erste Leitprinzip ist das ganze Argument: "Changelogs are for humans, not machines." Alles Weitere folgt daraus, dass eine Zielgruppe gewählt wurde.
Sechs Änderungstypen, nicht mehr: Wörtlich, wie der Standard sie schreibt — Added for new features; Changed for changes in existing functionality; Deprecated for soon-to-be removed features; Removed for now removed features; Fixed for any bug fixes; Security in case of vulnerabilities. „Breaking Changes“ ist keiner davon; ein Breaking Change steht unter Changed oder Removed, und der Bruch wird über die Versionsnummer signalisiert.
Die weiteren Leitprinzipien: "There should be an entry for every single version." "The same types of changes should be grouped." "Versions and sections should be linkable." "The latest version comes first." "The release date of each version is displayed." Und: der Bezug auf Semantic Versioning soll genannt werden.
[Unreleased] steht oben: Version 2.0.0 nennt die Mechanik: "Keep an Unreleased section at the top to collect upcoming changes. It shows readers what to expect, and at release time you move its contents into a new version." Dieser Abschnitt macht die Konvention durchhaltbar, weil Einträge entstehen, während die Änderung frisch ist.
ISO-Datum, größte Einheit zuerst: "Use the YYYY-MM-DD format. It orders from the largest unit to the smallest, avoids the confusion of regional date formats, and is an ISO standard." Also: ## [1.2.0] - 2026-10-03.
Die Konvention lehnt generierte Changelogs ausdrücklich ab: Version 1.1.0 sagt es direkt: "Using commit log diffs as changelogs is a bad idea: they’re full of noise." Version 2.0.0 formuliert die Position als Arbeitsteilung — "machines can draft, but humans curate" — und hält CI "in a supporting role" für "mechanical tasks: move the Unreleased section into a dated version at release time, check that the file is formatted correctly".

Wann einsetzen:

Beim Schreiben oder Umbauen einer CHANGELOG.md für eine Library oder ein Produkt mit externen Nutzern
Gemeinsam mit semantic-versioning, auf das die Konvention ausdrücklich verweist und das die Versionsnummern der Abschnitte liefert
Um die Frage zu entscheiden, was in einen Release-Eintrag gehört: sichtbare, nennenswerte Änderung ja; internes Refactoring und Tippfehler nein
Bei der Prüfung eines Release-Prozesses, dessen Changelog ein git log-Abzug ist — und bei der Frage, ob den jemand liest
Wenn ein LLM Release Notes schreiben soll: das Benennen der Konvention erzeugt die sechs richtigen Kategorien statt einer plausibel aussehenden Menge

Häufige Missverständnisse:

❌ „Breaking Changes ist einer der Standardabschnitte“ — ist er nicht; die sechs Typen sind fest, und das ist der häufigste Fehler
❌ „Keep a Changelog ist ein Tool“ — es ist eine Konvention für eine einfache Textdatei; die Tools sind andere Projekte
❌ „Der Changelog wird aus dem Commit-Log generiert“ — die Konvention sagt in beiden veröffentlichten Versionen das Gegenteil
❌ „Jeder Commit braucht einen Eintrag“ — nur nennenswerte Änderungen; das Kuratieren ist die Arbeit
✓ „Maschinen entwerfen, Menschen kuratieren“ — die Formulierung des Standards selbst für die Grenze der Automatisierung

Kritik:

Die Gegenposition wird von der Conventional-Commits-Spezifikation offen vertreten, in ihren eigenen Worten. Ihre Liste der Vorteile beginnt mit "Automatically generating CHANGELOGs." und "Automatically determining a semantic version bump (based on the types of commits landed)." Genau das bestreitet Keep a Changelog: dass sich eine strukturierte Commit-Historie ohne Menschen in einen Changelog überführen lässt. Conventional Commits 1.0.0. Das darauf aufbauende Tool-Ökosystem nennt die Keep-a-Changelog-Seite 2.0.0 selbst: "A convention such as Conventional Commits, with tools such as semantic-release, release-please, Changesets, and git-cliff, reads structured commits to choose the next version and draft a changelog."
Die Antwort von Keep a Changelog, und der Satz, an dem das Argument hängt. "A commit and a changelog entry are written for different people, and one does not convert cleanly into the other." Keep a Changelog 2.0.0. Ob das zutrifft, ist eine empirische Frage über die eigene Zielgruppe: Bei einer internen Library, deren einzige Leser die Beitragenden sind, fallen beide Gruppen zusammen und der Einwand verliert seine Kraft.
Zwei namentliche Kritiker bestreiten, dass die Datei überhaupt ins Repository gehört. Josh Triplett bringt im Hacker-News-Thread zu Keep a Changelog den Versionsverwaltungs-Einwand: "Projects that still insist on maintaining a changelog file in git end up constantly fighting git’s conflict resolution, and they make rebase almost completely unusable. For an actual log of individual changes, that’s what 'git log' is for." Triplett (16.02.2015). Jan Krutisch, Mitgründer von Depfu, räumt der generierten Seite mehr ein als die Konvention — "If you are willing to use (and enforce) a specific format for your commit messages, the results can be pretty decent" — und benennt den Preis des Handbetriebs: "the further away you move the changelog writing from the actual code changes, the higher are the chances to either forget things or to actually get details wrong". Krutisch, „Changelogs: To write or to generate?“ (02.10.2018). Ein reiner Gegner ist er nicht: Er schließt mit "If in doubt, use the simple, handwritten approach."
Was nicht gefunden wurde. Kein namentlicher Kritiker des Formats selbst — der sechs Änderungstypen, des [Unreleased]-Abschnitts, der Reihenfolge. Gesucht auf Englisch und Deutsch. Der belegte Streit dreht sich darum, wer die Datei schreibt und wo sie liegt, nicht darum, wie sie aufgebaut ist.

Aktueller Stand:

Zwei veröffentlichte Versionen — und die Startseite verweist nicht auf die neuere. Version 2.0.0 erschien am 7. Juni 2026, keepachangelog.com verlinkt „Continue to Keep a Changelog“ aber weiter auf /en/1.1.0/. Das Format lässt sich gefahrlos zitieren, eine Versionsnummer nur mit Prüfung. 1.1.0 — 2.0.0. Erstellt und gepflegt von Olivier Lacan, gestaltet von Tyler Fortune.
Das Format selbst ist nicht gewandert. Die sechs Änderungstypen, der [Unreleased]-Abschnitt, YYYY-MM-DD und die neueste Version zuerst sind in 1.1.0 und 2.0.0 identisch. Neu in 2.0.0 ist die ausdrückliche Haltung zur Automatisierung.
Der Anchor bringt Korrektheit, nicht Erinnerung. Zwei von vier Baselines ohne Anchor auf claude-haiku-4-5 nannten die Konvention von selbst — und listeten dann die falschen Abschnitte; eine produzierte „Breaking Changes, New Features, Fixed, Deprecated“, was nicht die Menge des Standards ist. Mit dem benannten Begriff kamen alle sechs kanonischen Typen plus [Unreleased]. Ein dichter Prior, dessen Details regelmäßig falsch erinnert werden — genau der Fall, in dem Benennen sich auszahlt.