Changelog

Ausführliche Erklärung

Changelogs werden üblicherweise rückwaerts chronologisch dargestellt – die neuesten Änderungen oben. Jeder Eintrag enthaelt mindestens ein Datum (oder eine Version), eine Kategorisierung (Hinzugefuegt, Geaendert, Behoben, Entfernt) und eine kurze, verständliche Beschreibung. Technische Detail-Tiefe sollte sich an der Zielgruppe orientieren – ein Endkunden-Changelog beschreibt Nutzen, ein Entwickler-Changelog kann konkret API-Veränderungen nennen.

Die Convention „Keep a Changelog" (keepachangelog.com) hat sich als Quasi-Standard etabliert. Sie schlaegt sechs Kategorien vor: Added (Neues), Changed (Änderungen an Bestehendem), Deprecated (bald-entfernte Features), Removed (entferntes Verhalten), Fixed (Bug-Fixes), Security (sicherheitsrelevante Änderungen). Diese Kategorisierung hilft Nutzern, sofort einzuschaetzen, ob ein Eintrag für sie relevant ist.

Changelog und Release Note unterscheiden sich im Detailgrad. Eine Release Note ist meist eine ausführlichere Marketing-Beschreibung eines größeren Releases, oft mit Screenshots und Use-Case-Beispielen. Ein Changelog ist eine knappe, vollständige Liste auch kleinerer Änderungen. Viele Produkte führen beides parallel.

Ein gut gepflegter Changelog ist ein machtvolles Kommunikationsinstrument. Anwender bemerken bei jedem Login, dass sich das Produkt weiterentwickelt – das schafft Vertrauen und reduziert Churn. Gleichzeitig dient er als Beleg, dass eingereichte Feature Requests tatsächlich umgesetzt werden, und schließt damit den Feedback-Loop.

Technisch wird der Changelog häufig als Markdown-Datei (CHANGELOG.md im Repository) oder als dedizierte Seite („/changelog") gepflegt. Bei größeren Produkten generieren CI-Pipelines die Changelog-Eintraege halbautomatisch aus Pull-Request-Titeln, um manuelle Pflege zu reduzieren. Wichtig ist ein konsistenter Veroeffentlichungs-Rhythmus – wenn der Changelog Wochen oder Monate stillsteht, verliert er an Glaubwürdigkeit.