Software-Release-Notes: Was sie sind und was hineingehört

Software-Release-Notes sind das Dokument, das eine Softwareversion begleitet und der Leserin sagt, was sich geändert hat, wen die Änderung betrifft und was sie gegebenenfalls tun muss. Sie entstehen einmal pro Release und werden von Leuten gelesen, die über ein Upgrade entscheiden, von Leuten, die prüfen, ob ein Problem behoben ist, und von Leuten, die das Produkt supporten. Gute Notes sind kurz, auf die Version zugeschnitten und ehrlich bei allem, was etwas kaputt macht.

Was sind Software-Release-Notes?

Sie sind die datierte, versionierte Zusammenfassung eines Releases. Eine Release Note beantwortet für eine Leserin, die nicht dabei war, drei Fragen: Was ist anders, betrifft es mich, und muss ich handeln. Die gesamte Geschichte des Projekts ist der Changelog, und das Commit-Log gehört den Leuten, die den Code geschrieben haben.

Dieselben Fakten können in einem Changelog-Eintrag und in Release Notes stehen. Der Unterschied liegt in Auswahl und Zielgruppe: Der Changelog listet jede nennenswerte Änderung, die Release Notes beginnen mit denen, die eine Leserin bemerken wird, und erklären sie. Changelog vs. Release Notes zieht die Linie genauer.

Was gehört in Software-Release-Notes?

Nehmt Version und Datum auf, eine Zusammenfassung in einem Absatz und dann die Änderungen, gruppiert danach, was die Leserin damit tun kann. Sagt bei jeder Änderung, was in ihren Worten anders ist, wen es betrifft und ob sie handeln muss.

Ein vollständiger Satz besteht aus diesen Teilen:

1. Versionsnummer und Release-Datum. Benutzt das Format eurer Tags, damit die Leserin die Notes einem Build zuordnen kann.
2. Eine Zusammenfassung. Zwei oder drei Sätze: wofür dieses Release da ist und ob das Upgrade etwas von der Leserin verlangt.
3. Neue Features und Verbesserungen. Was die Leserin jetzt tun kann, nicht, was der Code jetzt enthält.
4. Fixes. Das Symptom, das verschwunden ist, und die Version, in der es anfing.
5. Breaking Changes und Deprecations. Was nicht mehr funktioniert, ab wann und was man stattdessen nimmt. Gibt es welche, stehen sie ganz oben.
6. Bekannte Probleme. Alles, was ihr ausgeliefert habt und von dem ihr wisst, dass es nicht stimmt, mit Workaround, falls es einen gibt.
7. Voraussetzungen und Upgrade-Schritte. Unterstützte Plattformen, Mindestversionen, Migrationsbefehle.

Lasst Refactorings, Dependency-Bumps ohne sichtbare Wirkung und interne Tickets weg. Kann eine Leserin die Änderung nicht bemerken, gehört sie in die Git-Historie. Wie man Release Notes schreibt behandelt Formulierung und Reihenfolge.

Wie sieht eine Software Release Note aus?

Hier eine kurze für ein erfundenes Kommandozeilen-Tool. Die Form zählt mehr als der Inhalt.

## 2.4.0 (2026-10-08)

Schnellere Exporte und eine Breaking Change an der Config-Datei.
Das Upgrade braucht eine einzeilige Änderung an `tool.yml`.

### Breaking
- `output:` in `tool.yml` heißt jetzt `export.path:`. Alte Configs
  scheitern mit "unknown key". Benennt den Key um, mehr nicht.

### New
- Exporte werden direkt auf die Platte gestreamt, Dateien über
  100 MB laufen nicht mehr in einen Timeout.

### Fixed
- Die Suche funktioniert wieder für Anfragen mit Bindestrich.
  Kaputt seit 2.3.0.

### Known issues
- Windows-Pfade über 260 Zeichen scheitern weiterhin. Nehmt
  vorerst ein kürzeres Ausgabeverzeichnis.

Die Breaking Change steht zuerst, mit genau dem Fehlertext, den die Leserin sehen wird, weil Leute nach Fehlermeldungen suchen. Der Fix nennt die Version, in der es kaputtging, damit die Leserin ihn dem Beginn ihres Problems zuordnen kann. Das bekannte Problem hat einen Workaround, und das ist besser als Schweigen. Release-Notes-Beispiele enthält mehr Formulierungen für jede Art von Eintrag.

Wie unterscheiden sich Software-Release-Notes je nach Zielgruppe?

Haltet eine Quelle der Wahrheit und schreibt pro Zielgruppe eine Version. Die Fakten ändern sich nicht, der Detailgrad schon. Kundinnen wollen den Nutzen in einer Zeile, Administratorinnen Voraussetzungen und bekannte Probleme, Entwicklerinnen exakte Namen und Versionen, und der Support will wissen, was er sagt, wenn ein Ticket eingeht.

Bei API-Produkten braucht die Entwicklerversion die meiste Sorgfalt, denn was für euch ein kleiner Fix ist, kann für die aufrufende Seite ein Ausfall sein. API-Changelog und Breaking Changes behandeln diese Zielgruppe. Für die interne Version beschreibt interne Release Notes, was Support und Vertrieb brauchen und Kundinnen nicht.

Wo sollte man Software-Release-Notes veröffentlichen?

Veröffentlicht sie dort, wo die Leserin ohnehin ist, wenn sie die Frage stellt. Bei einer Mobile-App ist das der Store-Eintrag, in dem die Plattform für jede Version ein Release-Notes-Feld vorsieht; Apple dokumentiert, wie man Release Notes für Builds angibt. Bei einem Webprodukt ist es eine Changelog-Seite, die aus der App verlinkt ist. Bei einer Bibliothek sind es die Release-Seite und eine Datei im Repository, wie in GitHub Release Notes beschrieben.

Gebt jeder Version eine stabile URL, damit der Support darauf verweisen kann, und behaltet alte Versionen. Wer auf 2.2 sitzt, braucht auch die Notes zu 2.3 und 2.4. Als Startstruktur liefert die Release-Notes-Vorlage Überschriften zum Kopieren.

Wie lang sollten Release Notes sein?

So lang, wie die Änderung es braucht, und nicht länger. Ein Patch-Release kann drei Zeilen haben. Ein Major-Release mit Migration braucht eine Seite und wahrscheinlich einen eigenen Migrationsleitfaden, der von den Notes verlinkt wird. Der Test: Weiß eine Leserin, die nur den ersten Bildschirm überfliegt, ob das Release sie betrifft? Falls nicht, zieht die Zusammenfassung nach oben und kürzt den Rest. Release Notes Best Practices listet auf, was sich bewährt und was nur Gewohnheit ist.

FAQ

Was sind Software-Release-Notes? Sie sind eine versionierte Zusammenfassung dessen, was sich in einem Release einer Software geändert hat, geschrieben für die Leute, die sie nutzen oder supporten. Sie decken neue Features, Fixes, Breaking Changes und alles ab, was die Leserin tun muss.

Was ist der Unterschied zwischen Release Notes und einem Changelog? Ein Changelog ist die vollständige laufende Aufzeichnung nennenswerter Änderungen. Release Notes sind eine Nachricht zu einem Release, ausgewählt und umgeschrieben für Leserinnen, die über ein Upgrade entscheiden. Viele Teams veröffentlichen den Changelog-Eintrag einer Version als deren Release Notes.

Wer schreibt Software-Release-Notes? Meistens die Product Managerin, ein Technical Writer oder die Entwicklerin, die die Änderung ausgeliefert hat, und jemand prüft den Ton. Am besten wird es, wenn die Person, die der Änderung am nächsten ist, entwirft und eine zweite Person es für die Leserin redigiert.

Brauchen kleine Releases Release Notes? Ja, kurze. Auch ein Patch-Release sollte sagen, was behoben wurde und ob die Leserin handeln muss. Eine einzeilige Notiz ist besser als keine, denn “Fehlerbehebungen und Verbesserungen” sagt der Leserin nichts.

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.

Mehr bei changeloop: Vorlage für Release Notes, Changelog-Beispiele