Changelog-Beispiele

1. Ein gewöhnliches SaaS-Release

Der Normalfall: eine Handvoll für Nutzende sichtbarer Änderungen, keine Migration, kein Drama. Es ist kurz, weil das Release klein war, und dem Drang zum Auffüllen zu widerstehen ist der größte Teil des Handwerks.

## 20. August 2026

### Neu
- Gespeicherte Ansichten im Postfach. Einen Filter einmal anpinnen und
  aus der Seitenleiste wiederverwenden.

### Verbessert
- Der Export-Job meldet jetzt den Fortschritt, statt bei großen Konten
  hängen zu wirken.

### Behoben
- Eingeladene Mitglieder sehen vor ihrer ersten Anmeldung kein leeres
  Dashboard mehr.

2. Ein API-Release mit einer Deprecation

Wer ein API-Changelog liest, sucht eine einzige Information: ob die eigene Integration gleich bricht und wie viel Zeit bleibt. Setzen Sie das nach oben und geben Sie ihm ein Datum.

## Acme API 4.2 - 20. August 2026

### Breaking Changes
- `?page=` entfällt auf allen List-Endpunkten. Verwenden Sie den Wert
  `nextCursor` aus der vorherigen Antwort.
  `?page=` liefert nach dem 1. Oktober 2026 ein 400.
  Migrationsschritte: acme.example/docs/pagination

### Neu
- Webhooks lassen sich auf ein einzelnes Projekt eingrenzen.

### Verbessert
- List-Endpunkte antworten bei Konten mit über 10.000 Datensätzen
  rund viermal schneller.

3. Ein Mobile-Release

App Stores zeigen ein gekürztes Feld „Was ist neu“, und die Prüfung kann einen Build tagelang aufhalten. Beides prägt den Eintrag.

## iOS 3.4.0 - 20. August 2026

Offline-Modus. Öffnen, lesen und schreiben ohne Verbindung;
alles synchronisiert sich, sobald Sie wieder online sind.

### Ebenfalls in diesem Release
- Schnellerer Start auf älteren Geräten.
- Absturz beim Öffnen eines geteilten Links aus Mail behoben.

4. Ein Sicherheitsfix

Der eine Eintrag, bei dem weniger zu sagen richtig ist. Nutzende müssen wissen, dass sie aktualisieren sollten; niemand sonst braucht eine Beschreibung, die präzise genug ist, um die noch nicht aktualisierte Version anzugreifen.

## 20. August 2026

### Sicherheit
- Die Prüfung von Session-Tokens wurde gehärtet. Konten auf
  selbst gehosteten Installationen sollten auf 4.2.1 oder neuer
  aktualisieren. Verantwortungsvoll gemeldet; keine Hinweise auf
  eine Ausnutzung. Details: acme.example/security/2026-08

5. Wie ein schlechter aussieht

Jede Zeile hier ist in ihrer Form realistisch, und jede Zeile ist ein Fehler:

## v2.3.7

- PR #482 aus feature/inbox-refactor gemergt
- Bump lodash 4.17.20 -> 4.17.21
- Race Condition in MembershipCache.resolve() behoben
- Diverse Fehlerbehebungen und Verbesserungen
- SavedView-Modell refactored (danke, Dave!)

Was die guten gemeinsam haben

• Sie beschreiben ein Ergebnis, keine Umsetzung. Auch wer die Codebasis nie gesehen hat, erkennt, ob der Eintrag ihn betrifft.
• Sie lassen Dinge weg. Dependency-Bumps, Refactorings, CI-Änderungen und interne Umbenennungen fehlen, und genau dieses Fehlen hält den Rest lesbar.
• Sie stellen das Teure nach vorn. Wenn etwas bricht, ist das die erste Überschrift, mit Datum.
• Sie sind so datiert, dass Lesende etwas damit anfangen können: eine Versionsnummer dort, wo Nutzende Versionen sehen, ein Datum dort, wo sie es nicht können.
• Sie sind mit Absicht langweilig. Keine Ausrufezeichen, keine Marketing-Adjektive, kein „wir freuen uns, ankündigen zu dürfen“. Wer ein Changelog liest, sucht Informationen und nimmt alles übel, was ihm im Weg steht.

Häufige Fragen

Welches Format sollte ein Changelog verwenden?

keepachangelog.com ist das Nächste an einem Standard, und seine Abschnittsnamen (Added, Changed, Deprecated, Removed, Fixed, Security) sind weithin bekannt. Viel wichtiger ist die Formulierung innerhalb der Abschnitte. Ein einheitliches Format mit vagen Einträgen ist schlechter als ein lockeres Format mit konkreten.

Wie oft sollten wir veröffentlichen?

In dem Rhythmus, der zu Ihren Releases passt, und zwar beständig. Pro Release zu veröffentlichen ist die einfachste Regel. Einen Monat voller Releases in einen Beitrag zu bündeln macht jede einzelne Änderung später schwerer auffindbar, und später ist genau dann, wenn die meisten Menschen ein Changelog wirklich lesen.

Sollte das Changelog auf unserer Seite liegen oder auf einer Seite von Dritten?

Wenn möglich auf Ihrer Seite, weil dort der Traffic und der Suchwert anfallen und weil ein Changelog auf fremder Domain einen Klick von Ihrem Produkt entfernt ist statt Teil davon. Das ist das Argument dafür, es als Feed auszuliefern, den Sie selbst rendern, statt als gehostete Seite, die Sie verlinken.

Lesen Nutzende Changelogs überhaupt?

Ein kleiner Teil liest sie regelmäßig, ein sehr viel größerer durchsucht sie in dem Moment, in dem sich etwas unter ihnen verändert. Diese zweite Gruppe ist der Grund, das Symptom statt der Ursache zu schreiben: Sie sucht nach dem, was ihr passiert ist, in ihren eigenen Worten.

Weiterlesen: Changelog vs. Release Notes: Was ist der Unterschied? und Keep a Changelog, tatsächlich umgesetzt.