Die Release-Notes-Vorlage

Diese Release-Notes-Vorlage legt die 11 Abschnitte fest, die ein Team beim Release braucht, um Nutzern mitzuteilen, was sich geändert hat. Kopiere die gesamte Struktur ganz ohne Anmeldung, oder lade sie als PDF herunter.

Die Release-Notes-Vorlage (fertig zum Kopieren)

Der folgende Block ist die vollständige Vorlage, sofort kostenlos kopierbar, ganz ohne Anmeldung oder E-Mail-Schritt. Sie lässt sich unverändert in Word, Google Docs, Confluence, Notion oder eine Markdown-Datei einfügen, und das PDF enthält dieselben 11 Abschnitte, falls du sie lieber ausdrucken möchtest. Ersetze die Platzhalter in Klammern und lösche danach die Abschnitte, die dieses Release nicht betrifft.

[Produktname] Release Notes
Version: [x.y.z]
Release-Datum: [YYYY-MM-DD]
Plattform / Umgebung: [Web, iOS, Android, API, Staging]

Zusammenfassung der Änderungen (Zweck)
[Ein oder zwei Sätze: was dieses Release adressiert und wen es betrifft]

Neue Funktionen
- [Was der Nutzer jetzt tun kann, nicht der interne Funktionsname]

Verbesserungen und Erweiterungen (Leistungsverbesserungen)
- [Was bereits existierte, und was aus Sicht des Nutzers besser geworden ist]

Fehlerbehebungen
- Behoben: [was der Nutzer vorher gesehen hat, und was jetzt passiert]

Breaking Changes und Migrationsschritte
- [Was nicht mehr funktioniert], daher [was du ändern musst, und bis wann]

Bekannte Probleme und Workarounds (laufende Probleme)
- [Ungelöstes Problem] · [betroffene Plattform] · [Workaround] · [Zeitplan für den Fix]

Upgrade- oder Installationsschritte (Upgrade-Schritte / Installationshinweise)
1. [Was der Leser tun muss, um auf die neue Version zu kommen]

Deprecations
- [Funktion, Integration oder API] wird ab [Datum] eingestellt. [Worauf umgestellt werden soll]

Sicherheitshinweise
- [Sicherheitsrelevante Änderung, ohne Beschreibung der Schwachstelle]

Wo man Hilfe bekommt und Feedback gibt
- Docs: [Link] · Support: [E-Mail oder Kanal] · Feedback: [Link]

Was in eine Release-Notes-Vorlage gehört

Eine Release-Notes-Vorlage hat elf Abschnitte, jeder mit einer klaren Aufgabe. Schreibe jeden für die Person, die ihn liest: Entwickler und Kunden brauchen unterschiedliche Dinge.

So verwendest du die Release-Notes-Vorlage

1. Kopiere die Vorlage an den Ort, an dem dein Release ohnehin schon lebt. Sie lässt sich unverändert in Jira, Confluence, Notion, GitHub oder Azure DevOps einfügen, sodass die Notiz direkt bei der Arbeit steht statt in einem verlorenen Dokument.
2. Fülle zuerst die Kopfzeile aus. Produktname, Versionsnummer, Release-Datum und Plattform, damit jeder, der auf die Notiz stößt, sofort weiß, welchen Build sie beschreibt, noch bevor er ein Wort liest.
3. Sammle das Ship-Log und sortiere es danach, was der Nutzer sieht. Teile jede Änderung in neue Funktionen, Verbesserungen, Fehlerbehebungen und alles, was etwas kaputt macht, und lass Einträge weg, die für Nutzer unsichtbar bleiben.
4. Schreibe jeden Eintrag als Fähigkeit, nicht als Umsetzung. Aus „Batch-Verarbeitung implementiert" wird „Du kannst jetzt große Datensätze exportieren, ohne dass der Vorgang abbricht", was die Frage des Lesers beantwortet, ob dieses Release ihn überhaupt betrifft.
5. Füge überall dort einen Screenshot oder ein kurzes GIF hinzu, wo sich die Oberfläche geändert hat. Wenn ein Eintrag drei Absätze braucht, braucht er wahrscheinlich stattdessen ein fünfzehnsekündiges GIF.
6. Lösche die Abschnitte, die dieses Release nicht betrifft, und lass den Rest in der Reihenfolge stehen. Ein Patch lässt neue Funktionen und Upgrade-Schritte weg, und Nutzer sollten die Struktur nicht bei jedem Release neu lernen müssen.
7. Gib den Entwurf an eine benannte verantwortliche Person weiter, dann veröffentliche. Ohne eine einzige Person, die für die Freigabe verantwortlich ist, erscheint die Notiz zu spät oder gleich zweimal.

Release-Notes-Vorlage: ein ausgefülltes Beispiel

Das ist dieselbe Vorlage, ausgefüllt für ein fiktives Dispatch-Produkt, das ein Feature-Release veröffentlicht.

• Fieldpost 4.2.0 · Veröffentlicht: 12. März 2026 · Plattform: Web und iOS
• Zusammenfassung der Änderungen: Exporte werden jetzt bei großen Konten abgeschlossen, die kanadische Preisgestaltung stimmt, und selbst gehostete Admins haben einen Migrationsschritt.
• Neue Funktionen
• Geplante Exporte. Du kannst jetzt einen Bericht so einstellen, dass er jeden Montag läuft und in deinem Posteingang landet.
• Massen-Statusänderungen. Wähle bis zu 500 Aufträge aus und ändere ihren Status in einer einzigen Aktion.
• Verbesserungen und Erweiterungen
• Schnelleres Dispatch-Board. Das Board lädt bei Konten mit 10.000 offenen Aufträgen in etwa zwei Sekunden, gegenüber vorher neun.
• Fehlerbehebungen
• Behoben: Exporte über 50.000 Zeilen liefen in ein Timeout und gaben eine leere Datei zurück.
• Behoben: Preise wurden für kanadische Konten in USD angezeigt.
• Breaking Changes und Migrationsschritte
• Version 4.2.0 entfernt den v1-Endpunkt /exports. Richte Integrationen auf /v2/exports, der eine Job-ID zurückgibt. Selbst gehostete Installationen führen fieldpost migrate --v2-exports aus, bevor sie 4.2.0 starten.
• Bekannte Probleme und Workarounds
• Auf iOS laufen für Sonntag geplante Exporte stattdessen am Montag. Nutze bis zum Erscheinen von 4.2.1 am 26. März die Web-App.
• Upgrade- oder Installationsschritte
• Cloud-Konten laufen bereits auf 4.2.0. iOS-Nutzer aktualisieren bis zum 31. März über den App Store.
• Deprecations
• Fieldpost stellt das reine CSV-Berichtsformat zum 1. September 2026 ein. Stelle gespeicherte Berichte auf XLSX um.
• Sicherheitshinweise
• Sitzungstoken laufen jetzt nach 12 Stunden ab, und Admins können die Sitzungen anderer Nutzer beenden.
• Wo man Hilfe bekommt und Feedback gibt
• Docs: docs.fieldpost.example · Support: support@fieldpost.example · Feedback: der Feedback-Tab in der App.

Varianten der Release-Notes-Vorlage

Die fünf Varianten unten liegen auf zwei Achsen: wer die Notiz liest und welche Art von Release sie abdeckt. Jede behält die Kopfzeile und die Zusammenfassung der Änderungen bei und ergänzt, streicht oder schreibt die übrigen neun Abschnitte um. Die Unterschiede sind der eigentlich nützliche Teil, denn zu entscheiden, was bei einem kleinen Release gestrichen wird, ist der Punkt, den die meisten Teams falsch einschätzen.

Release-Notes-Vorlage für große Releases

Diese Variante nutzt alle 11 Abschnitte. Jede neue Funktion bekommt einen Absatz plus Screenshot oder GIF, Migrationsschritte werden ausgeschrieben statt nur verlinkt, und die Zusammenfassung der Änderungen wird so formuliert, dass sie für sich allein steht, denn das ist die Zeile, die Kollegen in Slack einfügen und dir später zitieren.

• Behält: alle 11 Abschnitte.
• Erweitert: neue Funktionen, Breaking Changes und Migrationsschritte, Upgrade-Schritte.
• Achtung: die Zusammenfassung muss auch ohne jeden anderen Abschnitt verständlich sein.

Release-Notes-Vorlage für Patches oder Hotfixes

Vier Abschnitte leisten den Großteil der Arbeit: Kopfzeile, Zusammenfassung, Fehlerbehebungen und, falls noch vorhanden, bekannte Probleme. Beginne mit dem Fix, dann wen er betrifft, dann ob der Leser etwas tun muss. Ein Hotfix-Hinweis, der mit einer Versionsnummer beginnt und den Fix im dritten Absatz vergräbt, verfehlt den Sinn, ihn schnell zu veröffentlichen.

• Lässt weg: neue Funktionen, Verbesserungen, Deprecations, Upgrade-Schritte.
• Behält: Kopfzeile, Zusammenfassung, Fehlerbehebungen, bekannte Probleme.
• Achtung: explizit angeben, wenn keine Aktion nötig ist.

Interne oder technische Release-Notes-Vorlage

Diese Variante schreibst du für das Team, das das System betreibt, also fällt die Nutzen-Formulierung weg und die Mechanik rückt in den Vordergrund. Nenne die betroffenen Services, die geänderte Konfiguration und alles, worauf ein Kollege um 2 Uhr nachts stoßen könnte.

• Ergänzt: Codeänderungen, API- und Datenbankänderungen, Umgebungs- und Konfigurationshinweise.
• Lässt weg: die nutzerorientierte Nutzen-Formulierung.
• Behält: Breaking Changes, bekannte Probleme, Upgrade-Schritte, die in dieser Variante mehr Gewicht tragen als in den anderen.

Release-Notes-Vorlage für mobile App-Stores

Store-Einträge begrenzen die Zeichenanzahl, daher komprimiert sich die gesamte Notiz auf eine Versionszeile und eine kurze „Was ist neu"-Liste. Schreibe drei bis fünf Aufzählungspunkte, jeder benennt eine Sache, die der Nutzer jetzt tun kann, geordnet nach Wichtigkeit für ihn.

• Behält: Kopfzeile, eine komprimierte Liste neuer Funktionen, eine Zeile für nennenswerte Fixes.
• Lässt weg: bekannte Probleme, Deprecations, Sicherheitshinweise, Migrationsschritte.
• Achtung: alles, was aus dem Store-Eintrag gestrichen wird, gehört trotzdem in die vollständige Notiz, die du selbst hostest.

Release-Notes-Vorlage für APIs

Diese Variante schreibst du für einen Entwickler, der gegen dich integriert, nicht für einen Endnutzer. Jeder Eintrag benennt den Endpunkt oder Parameter, den er betrifft, und jede Deprecation trägt ein Sunset-Datum, das der Leser in einen Kalender eintragen kann.

• Ergänzt: Endpunktänderungen, Parameteränderungen, ein Migrationsbeispiel mit Request und Response.
• Erweitert: Deprecations, mit Sunset-Daten, und Breaking Changes.
• Lässt weg: Screenshots und GIFs, die ein Entwickler-Leser nicht braucht.

Ein Sicherheitspatch übernimmt jeweils die Variante, die zum Release passt, mit einer zusätzlichen Regel: den Sicherheitshinweis sachlich halten und die Schwachstelle selbst nicht beschreiben.

Wann man eine Release-Notes-Vorlage einsetzt

Greife zur Vorlage bei jedem Release, das ein Nutzer sehen kann oder auf das er reagieren muss. Die drei häufigsten Auslöser sind ein Feature-Launch, eine Fehlerbehebung oder ein Hotfix, und ein interner Build. Sicherheitspatches, API-Releases und Store-Updates nutzen dieselbe Struktur mit unterschiedlich aktiven Abschnitten.

Release Notes, ein Changelog und Patch Notes beantworten unterschiedliche Fragen. Release Notes sind pro Release und menschenlesbar, geschrieben für die Zielgruppe, die die Änderung betrifft. Ein Changelog ist die vollständige chronologische Aufzeichnung, entwicklerorientiert und dauerhaft. Patch Notes sind der kurze Release-Hinweis für ein reines Fix-Release. Veröffentliche Release Notes, wenn jemand außerhalb des Teams reagieren muss, und führe den Changelog darunter durchgehend weiter.

Zuständigkeit funktioniert als Übergabe. Engineering liefert die Ship-Logs, ein PM oder PMM übersetzt sie in nutzerorientierte Einträge, und eine benannte Person gibt die Freigabe, bevor die Notiz erscheint.

Überspringe das leere Dokument: Nimm es stattdessen auf

Eine leere Vorlage auszufüllen ist der Schritt, den die meisten Teams aufschieben, bis das Release bereits draußen ist. Der andere Weg: Nimm die Walkthrough auf, die du ohnehin geben würdest, und lass sie zur Notiz werden.

Hinto AI verarbeitet jede Videoquelle, ob Loom, ein Zoom-Call, ein YouTube-Video oder eine lokale MP4-Datei, und nimmt deinen Bildschirm über die Web-App oder die Chrome-Erweiterung auf. Die KI-Aktionserkennung identifiziert Änderungen des UI-Zustands und Klicks auf Buttons und extrahiert daraus Screenshots und geschriebene Schritte. Diese Schritte werden zu den Einträgen für neue Funktionen, Verbesserungen und Fehlerbehebungen, und die GIF-Engine deckt die Stellen ab, an denen sich die Oberfläche geändert hat. Hinto liefert eine „Was ist neu"-Projektvorlage, die speziell für Release Notes aus Produkt-Demos gebaut ist.

Von dort aus überarbeitest du statt neu zu entwerfen: markiere einen Abschnitt und bitte die KI, ihn umzuschreiben, dann hoste das Ergebnis auf einer öffentlichen URL mit eigener Domain, oder synchronisiere es mit Notion, Confluence, GitHub oder GitLab.

FAQ zur Release-Notes-Vorlage

Was sollten Release Notes enthalten?

Elf Abschnitte: eine Kopfzeile; eine Zusammenfassung der Änderungen; neue Funktionen; Verbesserungen; Fehlerbehebungen; Breaking Changes und Migrationsschritte; bekannte Probleme; Upgrade-Schritte; Deprecations; Sicherheitshinweise; und wo man Hilfe bekommt. Die Zusammenfassung ist die Zeile, die Scanner lesen und Agenten zitieren.

Wie schreibt man gute Release Notes?

Beginne mit dem, was der Leser jetzt tun kann, und lass die Umsetzung außen vor. Aus „Batch-Verarbeitung implementiert" wird „Du kannst jetzt große Datensätze exportieren, ohne dass der Vorgang abbricht." Setze den Funktionsnamen fett, verwende die Labels „Neu", „Verbessert" und „Behoben", und halte Einträge auf zwei bis drei Sätze begrenzt.

Wer schreibt normalerweise Release Notes?

Ein Product Manager oder Product Marketing Manager, ausgehend von dem, was Engineering liefert. Engineering liefert die Ship-Logs, der PM oder PMM übersetzt sie in nutzerorientierte Einträge, und eine benannte verantwortliche Person gibt die Freigabe, bevor die Notiz veröffentlicht wird.

Was ist der Unterschied zwischen Patch Notes und Release Notes?

Patch Notes sind die Kurzform für ein reines Fix-Release. Sie lassen neue Funktionen, Verbesserungen, Deprecations und Upgrade-Schritte weg und beginnen mit dem Fix, wen er betrifft, und ob der Leser reagieren muss. Release Notes tragen die vollständige Struktur für ein Feature-Release.

Was sind Release Notes in Jira?

Es ist dasselbe Dokument, eingefügt in eine bestimmte Oberfläche. Wer nach Jira, Confluence, GitHub, Notion oder Azure DevOps sucht, möchte den Release-Hinweis selbst, also kopiere die obige Vorlage in die Oberfläche, die dein Team ohnehin schon liest. Hinto veröffentlicht nach Notion, Confluence, GitHub und GitLab.