Release Notes Beispiele: 5 ausgefüllte Vorlagen zum Kopieren

Diese Release Notes Beispiele decken fünf typische Release-Situationen ab: von der Feature-Ankündigung in einer SaaS-App über einen Hotfix und einen App-Store-Eintrag bis zur datierten API-Änderung und zur unternehmensweiten Umstellung auf ein neues IT-Tool. Produkt-, Entwicklungs- und IT-Teams können jedes dieser Beispiele als Text kopieren, und zu jedem gibt es ein passendes PDF.

Direkt zu den Beispielen springen.

Was ein gutes Release-Notes-Beispiel ausmacht

Jedes Muster in der Galerie verweist anhand der Nummer auf diese sieben Kriterien.

1. Kopfzeile mit Version und Datum. Beginnen Sie mit dem Produktnamen, der Versions- oder Build-Nummer, dem Veröffentlichungsdatum und, falls es je Plattform abweicht, dem Ort der Auslieferung (Web, iOS, API). Wer diese Zeile vermisst, kann nicht erkennen, ob die Notiz für die eingesetzte Version gilt.
2. Kurze Zusammenfassung oben. Ein bis drei Sätze vor jeder Liste sagen, wen die Änderung betrifft und wie. Ohne sie landen Leser direkt in den Stichpunkten.
3. Nutzenorientierte Formulierung. Jeder Eintrag beschreibt, was der Leser gewinnt oder woran er nicht mehr leidet („Sie können jetzt ...“). Schwache Formulierungen zählen interne Komponenten auf („Suchindex-Pipeline optimiert“).
4. Typisierte Änderungslabels. Einträge stehen unter einem Typ-Label wie Fixed oder Breaking, gleichartige Einträge sind gruppiert. Ohne Label lesen sich eine Reparatur und ein neues Feature gleich.
5. Konkrete Bugfixes als Vorher und Nachher. Jeder Fix stellt das Symptom, auf das jemand gestoßen ist, dem heutigen Verhalten des Produkts gegenüber, ein Fix pro Zeile. Die schwache Variante begnügt sich mit einer Sammelzeile.
6. Pflichtaktionen und Breaking Changes zuerst. Alles, was der Leser tun muss, steht weit oben, zusammen mit der Frist. Ist nichts nötig, steht dort „Keine Aktion erforderlich“. Schwache Notizen verstecken eine Breaking Change mitten in der Liste.
7. Bekannte Probleme und eine Anlaufstelle für Hilfe. Zu allem, was noch nicht funktioniert, gehört ein Workaround oder das Datum des Fixes, und die Schlusszeile verweist auf die Doku oder einen Support-Kontakt. Fehlt das, wirkt es, als sei nichts defekt.

5 Release Notes Beispiele zum Kopieren

Hier finden Sie fünf Muster, je eines pro Release-Typ, die wir zu den besten Release Notes Beispielen zum Übernehmen zählen. Alle darin vorkommenden Unternehmen sind frei erfunden.

Beispiel 1: SaaS-Feature-Launch

Für einen Product Manager, der ein einzelnes Feature in einer B2B-Rechnungs-App ankündigt.

• Kopfzeile: Ledgerly 3.8 · 6. Mai 2026 · Web · Tarife Growth und Scale
• Neu: Rechnungen mahnen jetzt von selbst
• Zusammenfassung: Ledgerly kann jetzt Zahlungserinnerungen nach einem Zeitplan versenden, den Sie festlegen, damit Finanzteams keine Nachfass-E-Mails mehr von Hand schreiben. Verfügbar in den Tarifen Growth und Scale.
• Was Sie jetzt tun können: bis zu 3 Erinnerungen pro Rechnung einrichten (zum Beispiel 3 Tage vor dem Fälligkeitsdatum, am Fälligkeitstag und 7 Tage danach). Die Erinnerungen enden automatisch, sobald die Zahlung erfasst ist. Jede Erinnerung nutzt Ihr Rechnungs-Branding.
• So nutzen Sie es: (1) Öffnen Sie Einstellungen > Erinnerungen. (2) Aktivieren Sie Automatische Erinnerungen. (3) Wählen Sie einen Zeitplan oder legen Sie einen eigenen an. (4) Klicken Sie auf Speichern. Der Zeitplan gilt für jede unbezahlte Rechnung.
• Sie wollten es, wir haben es gebaut: Feature-Wunsch Nr. 412 im Ledgerly-Feedback-Board (230 Stimmen).
• Verfügbarkeit: Der Rollout für alle Growth- und Scale-Konten läuft bis zum 20. Mai 2026.
• Bekannte Einschränkung: Erinnerungen werden nur auf Englisch versendet. Weitere Sprachen sind für das 3. Quartal 2026 geplant.
• Hilfe: help.ledgerly.example/reminders

Warum es funktioniert: Kriterien 1, 2, 3, 4 und 7. Der Titel ist selbst das Ergebnis.

Darauf achten: Die Beschränkung auf Englisch gilt nur für Ledgerly. Nennen Sie die Grenzen Ihres eigenen Features.

PDF herunterladen - Rechnungen mahnen jetzt von selbst

Beispiel 2: Update für den mobilen App Store

Ein Mobile-Product-Manager entwirft den Update-Text für beide App Stores.

• Kopfzeile: Trailmate · Neuigkeiten in Version 5.12 · 2. Juni 2026 · iOS und Android
• Offline-Karten werden jetzt im Hintergrund geladen, sodass Sie das Handy sperren und weiterwandern können.
• Neu: Eine Tempolinie im Höhendiagramm zeigt, wo Sie bei jedem Anstieg langsamer geworden sind.
• Behoben: Ihre GPS-Aufzeichnung bricht nicht mehr ab, wenn Sie mitten auf der Wanderung die Kamera öffnen.
• Behoben: Die Apple-Watch-App zeigt die Entfernung jetzt in Meilen an, wenn Ihr Handy auf Meilen eingestellt ist.
• Schlusszeile: Danke für die Meldungen, mit denen wir das beheben konnten. Fragen? support.trailmate.example

Mit Aufzählungszeichen und Zeilenumbrüchen kommen die vier Zeilen auf 341 von 500 Zeichen bei Google Play.

Warum es funktioniert: Kriterien 1, 2, 3, 4, 5 und 7. Jeder Fix benennt, was der Wanderer gesehen hat.

Darauf achten: Ein fünfter Stichpunkt könnte den Text über die Grenze von 500 Zeichen bei Google Play treiben.

PDF herunterladen - Neuigkeiten in Version 5.12

Beispiel 3: Bugfix-Patch-Release

Für einen Support-Leiter, der einen Live-Hotfix für eine Schichtplanungs-Software ankündigt.

• Kopfzeile: Rostra 2.14.1 Hotfix · 18. Juni 2026 · Web, iOS, Android
• Zusammenfassung: Dieser Hotfix behebt zwei Probleme, die mit 2.14.0 eingeführt wurden. Der Fix ist für alle Konten live. Es ist keine Aktion erforderlich.
• Behoben: Schichttausche, die in der mobilen App genehmigt wurden, erschienen erst nach einem Neuladen im Web-Dienstplan. Genehmigte Tausche erscheinen jetzt innerhalb von 5 Sekunden im Web.
• Behoben: Überstundenwarnungen wurden bei Konten mit Wochenbeginn am Montag schon bei 38 statt bei 40 Stunden ausgelöst. Warnungen werden jetzt bei 40 Stunden ausgelöst, und versehentlich versendete Warnungen wurden zurückgezogen.
• Betroffene Nutzer: Konten mit Wochenbeginn am Montag, die zwischen dem 16. und 18. Juni 2026 Überstundenwarnungen genutzt haben.
• Ursache: Die Einstellung für den Wochenbeginn wurde in UTC statt in der Zeitzone des Kontos gelesen.
• Bekanntes Problem: CSV-Exporte von Schichttauschen zeigen Zeiten weiterhin in UTC an. Der Fix erscheint am 25. Juni 2026 in 2.14.2.
• Hilfe: support@rostra.example

Warum es funktioniert: Kriterien 1, 2, 5, 6 und 7, mit „Es ist keine Aktion erforderlich“ gleich am Anfang.

Darauf achten: die Ursachenzeile. Halten Sie Ihre auf eine Zeile.

PDF herunterladen - Rostra 2.14.1 Hotfix

Beispiel 4: Änderung der API-Version

Ein Plattform-Team informiert Integratoren über eine datierte API-Version.

• Kopfzeile: Parcelo API Version 2026-07-01 · Veröffentlicht am 1. Juli 2026 · Aktion erforderlich bis 15. Januar 2027
• Zusammenfassung: Version 2026-07-01 ändert, wie Rates Preise zurückgeben, und benennt ein Feld um. Ihre Integration läuft auf der angepinnten Version weiter, bis Sie upgraden. Der v1-Labels-Endpunkt wird am 15. Januar 2027 abgeschaltet.
• Breaking: GET /rates gibt amount als Ganzzahl in Cent (1299) statt als Dezimalstring ("12.99") zurück.
• Breaking: Das Feld carrier heißt jetzt carrier_code.
• Neu (ohne Breaking Change): estimated_delivery (ISO-8601-Datum) bei jeder Rate.
• Deprecated: POST /v1/labels, Abschaltung am 15. Januar 2027. Nutzen Sie stattdessen POST /v2/labels.
• So führen Sie das Upgrade durch: (1) Senden Sie in einer Testumgebung den Header Parcelo-Version: 2026-07-01. (2) Teilen Sie amount überall durch 100, wo Sie Preise anzeigen. (3) Ersetzen Sie carrier durch carrier_code. (4) Verlagern Sie Label-Aufrufe auf /v2/labels.
• Vorher: {"carrier": "UPS", "amount": "12.99"}
• Nachher: {"carriercode": "ups", "amount": 1299, "estimateddelivery": "2026-07-04"}
• Hilfe: docs.parcelo.example/changelog/2026-07-01 und der Kanal #api in der Parcelo-Entwickler-Community.

Warum es funktioniert: Kriterien 1, 2, 3, 4, 6 und 7. Frist und Abschaltdatum stehen ganz oben.

Darauf achten: die Breaking Change beim Typ von amount. Geben Sie jeder Typänderung ein Vorher-Nachher-Snippet.

PDF herunterladen - Parcelo API Version 2026-07-01

Beispiel 5: Einführung eines internen IT-Tools

Für die IT-Abteilung, die bei Northwind Freight, einem Logistikunternehmen, ein Tool für rund 420 Beschäftigte ankündigt.

• Kopfzeile: IT-Release: Passwortmanager Vaultkey · Rollout vom 7. bis 21. Juli 2026 · Alle Beschäftigten
• Zusammenfassung: Vaultkey ersetzt die gemeinsame Tabelle „Team Passwords“. Alle wechseln in drei Wellen, und die Tabelle wird am 28. Juli schreibgeschützt.
• Rollout-Wellen: Finanzen und Personal am 7. Juli, Betrieb und Disposition am 14. Juli und alle übrigen am 21. Juli.
• Was sich für Sie ändert: Die Vaultkey-Browsererweiterung wird auf Firmenlaptops automatisch installiert. Team-Tresore ersetzen die Tabellenblätter. Die Tabelle wird am 28. Juli 2026 schreibgeschützt, und die IT archiviert sie am 31. August 2026.
• Was Sie tun müssen (Aktion erforderlich innerhalb von 2 Tagen nach Ihrer Welle): (1) Nehmen Sie die Einladungs-E-Mail von Vaultkey an. (2) Legen Sie ein Master-Passwort mit mindestens 14 Zeichen fest. (3) Optional: Installieren Sie die mobile Vaultkey-App.
• Bekanntes Problem: In Safari aktivieren Sie die Erweiterung selbst unter Einstellungen > Erweiterungen.
• Rollback: Die IT bewahrt die Sicherung der Tabelle bis zum 31. August 2026 auf.
• Hilfe: der Slack-Kanal #it-help und die IT-Sprechstunde dienstags und donnerstags um 14 Uhr.
• Verantwortlich: Priya Raman, IT Operations.

Warum es funktioniert: Kriterien 1, 2, 3, 6 und 7. Jede Aktion hat eine Frist.

Darauf achten: Die Daten sind fest in die einzelnen Wellen eingebaut. Verschiebt sich eine, senden Sie die Notiz erneut.

PDF herunterladen - IT-Release: Passwortmanager Vaultkey

So passen Sie ein Release-Notes-Beispiel an

1. Wählen Sie das Galeriemuster, das Ihrem Release-Typ am nächsten kommt. Entscheiden Sie nach Release-Typ: Feature-Launch, Store-Update, Hotfix, API-Änderung oder interner Rollout. Passt keines, ist die leere Release-Notes-Vorlage der Ausgangspunkt.
2. Richten Sie die Tiefe nach dem Umfang der Änderung. Große Launches verdienen Hintergrund und ein Bild. Kleine Anpassungen lassen sich in einer kurzen Übersicht bündeln, und ein Patch sollte mit dem beginnen, was er behebt.
3. Behalten Sie das Typ-Label und die kurze Zusammenfassung. Halten Sie an diesen beiden Feldern in jeder Größe fest, auch wenn Sie alles andere kürzen.
4. Formulieren Sie jeden Eintrag vom Ergebnis her. Ersetzen Sie Entwicklerbegriffe durch das Ergebnis, das ein Nutzer bemerkt.
5. Beantworten Sie „Betrifft mich das?“ schon im ersten Satz. Nennen Sie, wer profitiert oder wer handeln muss.
6. Prüfen Sie die Fakten mit dem Team, das es gebaut hat. Lassen Sie sich von den Entwicklern, die es ausgeliefert haben, Verhalten, Tarife, Plattformen und Version bestätigen, bevor die Notiz rausgeht.
7. Taggen Sie den Eintrag, damit Leser ihn später finden. Geben Sie ihm ein Datum, einen Änderungstyp, ein Tag für den Produktbereich und eine dauerhafte URL, und nutzen Sie bei jedem Release dasselbe Layout.

Wann Sie Release Notes brauchen

Große Releases, die mehrere Produkte oder Enterprise-Mandanten umfassen, brauchen Notes am dringendsten, weil Admins nach Produkt, Plattform und Version filtern müssen, um zu erkennen, was sie betrifft. Aber auch kleinere Releases brauchen sie: ein neues Feature in einer Web-App (Beispiel 1) oder einen Hotfix, bei dem die Anwender wissen wollen, ob ihr Problem gelöst ist (Beispiel 3).

Auf Mobilgeräten und bei APIs gelten harte Grenzen. Apple begrenzt den Update-Text auf 4.000 Zeichen im App Store, und Google erlaubt 500 bei Google Play (Beispiel 2). API-Integratoren sollten von einer Änderung erfahren, sobald eine Frist Codearbeit erzwingt (Beispiel 4).

Auch interne Tools zählen. Die Notiz sagt Support-Mitarbeitenden, Vertriebsleuten und Systemverantwortlichen, was sich geändert hat, wen sie fragen können und wie ein Rollback abläuft (Beispiel 5).

Häufige Fehler bei Release Notes

• Im Entwicklerjargon schreiben oder Tickets wörtlich kopieren. Eine Zeile wie „Suchindex-Pipeline optimiert“ oder eine rohe Commit-Nachricht sagt nichts über die Arbeit des Lesers. Die Leute hören auf zu lesen.
• Vage Einträge wie „Fehlerbehebungen und Leistungsverbesserungen“. Wer einen Bug gemeldet hat, kann nicht erkennen, ob er behoben wurde, und der Support bekommt das nächste Ticket.
• Breaking Changes und Pflichtschritte mitten in der Liste verstecken. Als ein Stichpunkt unter vielen bleibt eine Breaking Change unbemerkt, und Integrationen brechen, wenn die Frist abläuft.
• Ein langes, ungegliedertes Log ohne Zusammenfassung veröffentlichen. Ohne Zusammenfassung müssen Leser jeden Stichpunkt überfliegen, um zu erfahren, ob sie etwas angeht.
• Persönlichkeit die Änderung überdecken lassen. Wer nach einer Änderung sucht, findet sie nicht unter einer originellen Überschrift, die kein Feature nennt.

Die leere Seite überspringen: einfach aufnehmen

Teams, die jedes Release in einer Demo vorführen, können diese Sitzung aufzeichnen und an Hinto AI übergeben, dessen Vorlage „What's New“ einen ersten Entwurf der Notiz erstellt. Hinto akzeptiert Links zu Loom, Zoom und YouTube, Uploads als MP4, MOV und WebM sowie Bildschirmaufnahmen mit dem eigenen Recorder in der Web-App oder der Chrome-Erweiterung.

Bei der Verarbeitung des Videos erkennt Hinto Klicks auf Schaltflächen und Bildschirmwechsel und extrahiert daraus Screenshots und schriftliche Schritte. Für die Entwicklung kann eine aufgezeichnete Sprint-Demo zu einer durchsuchbaren Liste von Bugfixes werden.

Ein Abschnitt, der nicht stimmig klingt, lässt sich markieren und neu erzeugen, auch mit seinen Bildern. Die fertige Notiz kann auf einer öffentlichen Seite unter Ihrer eigenen Domain stehen, in über 50 Sprachen erstellt werden oder an Intercom, Notion, Confluence, GitHub oder GitLab gehen.

Release Notes FAQ

Welche Labels sollten Release Notes verwenden?

Beschränken Sie sich auf sechs: New, Improved, Fixed, Deprecated, Breaking und Known issue. Gruppieren Sie die Einträge nach Label, damit jeder Leser direkt zu dem Teil springen kann, der ihn betrifft. Ohne Labels gehen Fixes zwischen Features unter, und die Änderung, die ein bestimmter Nutzer braucht, übersieht man leicht.

Sollten Release Notes Screenshots oder Videos enthalten?

Bei sichtbaren Änderungen ja. Einen überarbeiteten Bildschirm erfassen Menschen mit einem kommentierten Bild, einem GIF oder einem kurzen Clip schneller als mit Fließtext, und der Verweis auf die Doku erspart Ihnen, in der Notiz ein Handbuch zu schreiben. Kleine Fixes brauchen nur Text.

Wie schreibt man Release Notes für eine API-Änderung?

Beginnen Sie mit den Code-Änderungen, die Integratoren Ihnen schulden, und ihrer Frist, abgesetzt unter einer eigenen Überschrift. Darunter listen Sie Breaking Changes, neue Felder und veraltete Endpunkte einzeln pro Zeile auf und nummerieren dann die Upgrade-Schritte. In Beispiel 4 steht in der Kopfzeile von Parcelo vor allem anderen „Aktion erforderlich bis 15. Januar 2027“.

Wie schreibt man Release Notes, die gelesen werden?

Beginnen Sie jeden Eintrag mit dem Nutzen, zum Beispiel „Große Exporte laufen nicht mehr in ein Timeout.“ Lassen Sie interne Komponentennamen weg. Beispiel 1 beginnt mit „Rechnungen mahnen jetzt von selbst“ und einer ergebnisorientierten Zusammenfassung, danach folgen die Einrichtungsschritte.

Verwandte Beispiele

Beispiele für Benutzerhandbücher, Beispiele für Wissensdatenbanken, Beispiele für Prozessdokumentation