Release Notes Vorlage: Format und Beispiele 2026

Eine Release Notes Vorlage ist eine feste Dokumentstruktur, die du für jedes Release ausfüllst. Sie enthält die Versionsnummer, das Release-Datum, eine kurze Zusammenfassung, neue Funktionen, Verbesserungen, Bugfixes, bekannte Probleme, Abkündigungen und alle Breaking Changes mit Upgrade-Schritten. Behalte die Reihenfolge immer bei, damit Leser wissen, wo sie nachschauen müssen.

Du hast etwas ausgeliefert. Jetzt hast du zwanzig Minuten, um es aufzuschreiben, bevor das Deploy-Fenster zugeht. Also kommt hier zuerst die Vorlage und danach die Begründung.

Release-Notes-Vorlage zum Kopieren

Kopiere das in dein Repo, auf deine Doku-Seite oder in den Body eines GitHub Release und füll die Klammern aus. Lösche jeden Abschnitt, der leer bleibt. Eine leere Überschrift "Bekannte Probleme" ist schlimmer als gar keine.

# [Produktname] [Versionsnummer]

**Veröffentlicht:** [JJJJ-MM-TT]
**Betrifft:** [Plattformen, Editionen oder Tarife]

## Zusammenfassung

[Ein oder zwei Sätze dazu, worum es in diesem Release geht.
Geschrieben für jemanden, der sonst nichts liest.]

## Neue Funktionen

### [Name der Funktion]
[Was du jetzt tun kannst, in einem Satz. Dann ein Satz dazu,
warum das hilft. Screenshot oder kurzes GIF dazu.]

### [Name der Funktion]
[Gleiche Form.]

## Verbesserungen

- [Schneller, klarer oder kleiner. Nenne Änderung und Wirkung.]
- [Eine Änderung pro Punkt.]

## Bugfixes

- [Behoben: das Symptom, das der Nutzer gesehen hat, nicht die
  interne Ursache.]
- [Behoben: gleiche Form.]

## Bekannte Probleme

- [Symptom, wen es betrifft, und der Workaround, falls es einen
  gibt.]

## Abkündigungen

- [Was wegfällt, was es ersetzt und ab wann es weg ist.]

## Breaking Changes und Upgrade-Schritte

1. [Genauer Schritt, in der richtigen Reihenfolge.]
2. [Nenne Befehl, Flag oder Einstellungsnamen.]
3. [Sag, wie man prüft, ob das Upgrade geklappt hat.]

## Danke an

Danke an [Namen oder Handles] für Meldung und Test.

Das ist die Langform. Die meisten Releases brauchen nicht alles davon. Deshalb teilt der nächste Abschnitt sie in drei Größen auf.

Die drei Vorlagen, die du wirklich brauchst

Teams bleiben hängen, weil sie ein einziges Dokument für jedes Release nutzen wollen. Ein Hotfix braucht keine Zusammenfassung. Eine kleine UI-Änderung braucht keine Upgrade-Schritte. Nimm die Form, die zur Größe der Änderung passt.

1. Major- oder Feature-Release

Nimm das, wenn du etwas Neues ausgeliefert hast, das Leute erst lernen müssen. Hier lohnt sich die volle Struktur, und hier lohnen sich Visuals.

# Acme 3.4.0

**Veröffentlicht:** 2026-08-09
**Betrifft:** Web, macOS, Windows

## Zusammenfassung

Gespeicherte Filter sind da. Du kannst jede Suche als benannten
Filter speichern und mit deinem Team teilen.

## Neue Funktionen

### Gespeicherte Filter
Speichere jede Suche aus der Toolbar und nutze sie mit einem
Klick wieder. Benannte Filter sehen alle im Workspace, also
musst du keine Query-Strings mehr in den Chat kopieren.

[Screenshot: die Filterleiste, Speichern-Button annotiert]

### Tastatur-Palette
Cmd K oder Ctrl K springt zu jedem Projekt, Filter oder Setting.

[GIF: 4 Sekunden, Palette öffnet und springt zu einem Projekt]

## Verbesserungen

- Die Board-Ansicht lädt in Workspaces mit über 5.000 Einträgen
  etwa doppelt so schnell.
- Der Export behält jetzt deine Spaltenreihenfolge.
- Datumsfelder nutzen die Zeitzone des Workspace.

## Bugfixes

- Behoben: Anhänge über 25 MB brachen den Upload still ab.
- Behoben: Die Seitenleiste klappte nach jedem Reload zu.
- Behoben: Neu eingeladene Nutzer sahen nach der Anmeldung
  einige Minuten eine leere Projektliste.

## Bekannte Probleme

- Gespeicherte Filter gibt es noch nicht in den Mobile-Apps.
  Filter aus dem Web erscheinen dort mit 3.5.

## Breaking Changes und Upgrade-Schritte

Die v1-Such-API ist ab jetzt nur noch lesend.

1. Stelle jedes Skript, das Filter schreibt, auf POST
   /v2/filters um.
2. Führe acme doctor --check-api aus, um zu prüfen, dass nichts
   mehr v1 aufruft.
3. v1 antwortet ab 2026-11-01 nicht mehr.

## Danke an

Danke an @dmitri und @sara-l für den Bug-Report zum Filter-Sharing.

2. Patch oder Hotfix in einer Zeile

Die meisten Releases sind genau das. Blas es nicht auf. Vier Zeilen sind eine vollständige, ehrliche Release Note.

# Acme 3.4.1

**Veröffentlicht:** 2026-08-12

- Behoben: Gespeicherte Filter mit einem Apostroph im Namen
  ließen sich nicht laden. Dein Filter ist intakt und
  funktioniert nach einem Reload wieder.

Das war es. Eine Version, ein Datum, ein Symptom, eine Beruhigung. Betroffene bekommen genau das, was sie brauchten. Alle anderen müssen keinen Absatz lesen.

3. Die "Neu"-Karte in der App

Die Karte, die in deinem Produkt aufgeht, hat eine andere Aufgabe. Sie ist keine Doku. Sie ist ein Zwei-Sekunden-Pitch für eine Änderung, und sie braucht ein Visual, weil eine reine Text-Karte weggeklickt wird.

Gespeicherte Filter

Speichere jede Suche als benannten Filter und teile sie mit
deinem Team. Keine Query-Strings mehr im Chat.

[GIF: 4 Sekunden, Filter speichern und einmal anklicken]

Alle Änderungen in 3.4.0 -> [Link zu den vollen Notes]

Zwei bis vier Zeilen, ein Visual, ein Link raus. Wenn du die Änderung nicht in zwei Zeilen beschreiben kannst, sind es wahrscheinlich zwei Änderungen.

Was in jeden Abschnitt gehört (und was raus kann)

Jeder Abschnitt hat eine Aufgabe. Hier ist die Aufgabe, dazu eine Zeile, die funktioniert, und eine, die es nicht tut.

Titel und Versionsnummer

Die Aufgabe: jemandem beim Scrollen helfen, das Release zu finden, das ihn betrifft. Nutze immer dasselbe Versionsschema. Semantic Versioning ist in Software aus einem Grund Standard: die Nummer selbst sagt dem Leser, ob das Release sein Setup kaputt macht.

• Gut: Acme 3.4.0
• Schlecht: August-Update (final, v2)

Release-Datum

Die Aufgabe: Lesern zeigen, ob ihr Bug schon behoben ist. Nutze ein eindeutiges Format. 2026-08-09 liest sich in jedem Land gleich. 08/09/2026 nicht.

• Gut: Veröffentlicht: 2026-08-09
• Schlecht: Veröffentlicht: letzten Donnerstag

Zusammenfassung

Die Aufgabe: den Leser bedienen, der sonst nichts liest. Ein oder zwei Sätze. Nenne die wichtigste Änderung und lass den Rest weg.

• Gut: "Gespeicherte Filter sind da. Du kannst jede Suche als benannten Filter speichern und mit deinem Team teilen."
• Schlecht: "Dieses Release enthält eine Reihe von Erweiterungen, Optimierungen und Fehlerbehebungen über die Plattform hinweg."

Bei einem Patch lässt du die Zusammenfassung ganz weg. Es gibt nichts zusammenzufassen.

Neue Funktionen

Die Aufgabe: eine Fähigkeit vermitteln. Eine Überschrift pro Funktion, ein Satz dazu, was der Leser jetzt kann, einer dazu, warum das zählt, und ein Visual. Das ist der Abschnitt, der einen Screenshot rechtfertigt.

• Gut: "Speichere jede Suche aus der Toolbar und nutze sie mit einem Klick wieder."
• Schlecht: "FilterPersistenceService mit Workspace-Scoping ergänzt."

Verbesserungen

Die Aufgabe: Änderungen abdecken, die man nicht erklären muss. Kleine Gewinne an bestehendem Verhalten kommen hier als einfache Punkte hin. Nenne Änderung und Wirkung in derselben Zeile.

• Gut: "Der Export behält jetzt deine Spaltenreihenfolge."
• Schlecht: "Verschiedene UX-Verbesserungen."

"Verschiedene Verbesserungen" ist die Formel, die Leser gelernt haben zu überspringen. Wenn du sie nicht benennen kannst, braucht sie keine Zeile.

Bugfixes

Die Aufgabe: Lesern erlauben, ihr eigenes Problem zu erkennen. Beschreibe das Symptom, das sie gesehen haben, nicht den Code, den du geändert hast. Lass die interne Ticket-ID aus allem raus, was Kunden sehen.

• Gut: "Behoben: Anhänge über 25 MB brachen den Upload still ab."
• Schlecht: "ACME-4417 im Upload-Chunker behoben."

Behalte die Ticket-ID in der internen Version, wenn dein Team sie zur Nachverfolgung braucht. Zwei Zielgruppen, zwei Dokumente, eine Quelle.

Bekannte Probleme

Die Aufgabe: Vertrauen kaufen und Support-Tickets sparen. Ein Problem zu benennen, bevor ein Nutzer es findet, macht aus einer Beschwerde ein Schulterzucken. Nenne Symptom, Betroffene und Workaround.

• Gut: "Gespeicherte Filter gibt es noch nicht in den Mobile-Apps. Filter aus dem Web erscheinen dort mit 3.5."
• Schlecht: (Schweigen, dann vierzig Support-Tickets)

Abkündigungen

Die Aufgabe: Leuten Zeit geben. Sag, was wegfällt, was es ersetzt und ab wann es nicht mehr geht. Eine Abkündigung ohne Datum ist eine Überraschung mit Anlauf.

• Gut: "Die v1-Such-API ist ab heute nur noch lesend und antwortet ab 2026-11-01 nicht mehr. Nutze stattdessen POST /v2/filters."
• Schlecht: "Alte Endpunkte werden in einem künftigen Release entfernt."

Breaking Changes und Upgrade-Schritte

Die Aufgabe: einen Leser ohne Support-Anruf von der alten auf die neue Version bringen. Nummerierte Schritte, in der richtigen Reihenfolge, mit dem genauen Befehl oder Einstellungsnamen. Zum Schluss: wie man prüft, dass es geklappt hat.

• Gut: "Führe acme doctor --check-api aus, um zu prüfen, dass nichts mehr v1 aufruft."
• Schlecht: "Passe deine Integrationen entsprechend an."

Danke an

Die Aufgabe: dafür sorgen, dass sich Bug-Melden lohnt. Eine Zeile mit den Namen der Leute, die gemeldet und getestet haben. Kostet nichts und hebt sichtbar die Qualität der nächsten Meldungen.

Release Notes, Changelog, Patch Notes und "Neu" im App Store

Diese vier Begriffe werden durcheinander benutzt, und sie sind nicht dasselbe Dokument. Wer das trennt, spart sich Diskussionen über Ton und Länge.

Ein Changelog ist ein vollständiger Datensatz, der nur wächst. Das Format Keep a Changelog ist die verbreitete Konvention: eine Datei, neueste Version oben, Änderungen gruppiert unter Added, Changed, Deprecated, Removed, Fixed und Security. Es ist für den Leser gedacht, der jede Änderung will.

Release Notes sind kuratiert. Du wählst aus, was zählt, und lässt Dinge absichtlich weg. Genau das ist der Unterschied: ein Changelog ist vollständig, Release Notes sind redigiert.

Patch Notes sind der schmale Fall: ein kleiner Build, eine kurze Liste, meist nur Fixes. Der Begriff kommt aus Games und hat sich gehalten, weil er ehrlich zum Umfang ist.

Der "Neu"-Text im App Store hat eigene Grenzen. Apples Anleitung im App Store Connect zum Aktualisieren der App-Version erklärt das Feld selbst, und praktisch gilt: die meisten Leute sehen nur die ersten zwei Zeilen, bevor sie auf "mehr" tippen. Fang mit der einen Änderung an, die zählt, und liefere nie "Bugfixes und Performance-Verbesserungen" als kompletten Eintrag. Bei Windows- und Enterprise-Produkten ist der Druck umgekehrt: Microsofts eigene Windows Release Health Notes zeigen, wie viel Build- und Servicing-Detail Admins erwarten, wenn sie die Zielgruppe sind.

So schreibst du eine Änderung, die Nutzer verstehen

Die meisten Release Notes sind nicht schlecht strukturiert. Sie sind schlecht formuliert. Diese fünf Übungen reparieren fast jede Zeile.

Fang mit dem an, was der Leser jetzt kann

Beginne den Satz mit der Fähigkeit, nicht mit der Mechanik. Deinen Leser interessiert nicht, welchen Service du refactored hast.

• Vorher: "Inkrementelles Indexing in der Such-Pipeline umgesetzt."
• Nachher: "Suchergebnisse erscheinen jetzt beim Tippen, auch in Workspaces mit 100.000 Einträgen."

Interne Namen raus aus Kundentexten

Komponentennamen, Servicenamen und Ticket-IDs sind interne Kürzel. Für Leser bedeuten sie nichts. Schlimmer: sie lassen die Notes wie einen geleakten Jira-Export aussehen. Wenn du Details direkt aus Tickets ziehst, übersetze sie. Dieselbe Disziplin, die eine Bug-Report-Vorlage für Entwickler nützlich macht, macht eine Release Note für Kunden nützlich. Unser Guide dazu, wie du saubere Details aus einer Ticket-Queue mit Screenshots in Jira holst, deckt die Quellseite dieses Workflows ab.

• Vorher: "Null-Reference im NotificationDispatcher behoben (ACME-4417)."
• Nachher: "Behoben: Kommentar-Benachrichtigungen kamen nach dem Umbenennen eines Projekts nicht mehr an."

Eine Änderung pro Punkt

Zwei Änderungen in einem Punkt heißt, dass eine davon übersehen wird. Trenne sie. Listenpunkte sind billig.

• Vorher: "Export-Performance verbessert und Spaltenreihenfolge-Bug behoben und CSV ergänzt."
• Nachher: drei Punkte.

Verb zuerst, Präsens

"Du kannst jetzt als CSV exportieren" schlägt "CSV-Export wurde ergänzt". Aktiv ist kürzer und setzt den Leser in den Satz. Bei Fixes liest sich die Form "Behoben: [Symptom]" am schnellsten, weil das erste Wort schon den Typ des Punkts verrät.

Nenne die Zahl, wenn du eine hast

"Schneller" ist eine Behauptung. "In Workspaces mit über 5.000 Einträgen etwa doppelt so schnell" ist eine Angabe, die ein Leser prüfen kann. Zahlen schützen dich außerdem: eine begrenzte Aussage lässt sich nicht als Versprechen für jedes Setup lesen.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 39 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

Screenshots und GIFs in Release Notes

Hier kommt der Teil, den keine Vorlage abdeckt. Jeder Guide sagt dir, du sollst Visuals einbauen. Keiner sagt dir, wie du sie produzierst. Deshalb schreiben so viele Teams die Notes in zehn Minuten und kämpfen danach eine Stunde mit Bildern.

Ein paar Regeln machen die visuelle Ebene wiederholbar.

Ein annotierter Screenshot pro ausgelieferter Funktion

Nicht pro Release, pro Funktion. Ein Screenshot ohne Annotation ist nur ein Bild deiner App. Setz einen Pfeil auf das neue Element und ein kurzes Textlabel daneben, das sagt, was es tut. Diese eine Annotation ist der Unterschied zwischen "hier ist der Screen" und "hier ist die Änderung".

Verbesserungen und Bugfixes brauchen meist gar kein Bild. Versuch nicht, einen schnelleren Export zu illustrieren.

Ein kurzes GIF für alles Interaktive

Wenn eine Änderung nur in Bewegung Sinn ergibt (eine Drag-Interaktion, ein aufgehendes Panel, ein Ablauf über mehrere Schritte), nimm 3 bis 6 Sekunden auf. Nicht dreißig. Starte die Aufnahme ein Bild vor der Aktion und stoppe sie ein Bild nach dem Ergebnis.

Auf dem Mac hilft dir unsere Anleitung dazu, wie du GIFs auf dem Mac aufnimmst, und für Windows gibt es das Gegenstück zum Bildschirm als GIF aufnehmen unter Windows. Ist die Aufnahme zu lang geworden, schneide sie zuerst und komprimiere danach: unser kostenloser Video-Trimmer kürzt eine lange Aufnahme auf die fünf Sekunden, die die Änderung wirklich zeigen.

Halte die Bildmaße über Releases hinweg gleich

Das ist der billigste Qualitätsgewinn, den du haben kannst. Leg eine Breite fest, schreib sie in deinen Release-Prozess und weiche nie davon ab. Wenn jedes Release denselben Rahmen nutzt, liest sich deine Notes-Seite als Serie. Wenn die Maße wechseln, sieht die Seite improvisiert aus, selbst wenn der Text stark ist.

Dasselbe Prinzip trägt gute Screenshots in technischer Dokumentation: Gleichmäßigkeit ist es, was eine Bildserie bewusst wirken lässt.

Kundendaten verpixeln oder unscharf machen

Release-Screenshots entstehen oft in einem echten Account, weil dort realistische Daten liegen. Namen, E-Mail-Adressen, Rechnungsnummern und Workspace-Namen leaken genau so. Mach sie unscharf oder verpixele sie, bevor das Bild deinen Rechner verlässt, nicht erst, wenn es jemand meldet.

Nummeriere Änderungen über mehrere Schritte

Wenn eine neue Funktion drei Aktionen braucht, setz nummerierte Marker auf einen Screenshot statt drei Bilder auszuliefern. Eine Zähler-Annotation hält den ganzen Ablauf in einem Bild. Unser Guide zu Schritt-für-Schritt-Anleitungen mit Screenshots geht tiefer auf die Reihenfolge solcher Visuals ein.

Hoste die Bilder, häng sie nicht an

Ein 4 MB großes PNG in einen Newsletter zu kleben, ist der Weg zu ungelesenen Release Notes. Lade das Bild hoch, hol dir einen Link und verweise auf den Link. Das hält die Notes leicht und du kannst einen falschen Screenshot tauschen, ohne das ganze Dokument neu zu veröffentlichen. Unser Guide zum Screenshot-Teilen über die Cloud deckt die Hosting-Seite und die Abwägungen ab.

Das Visual aufzunehmen ist der eine Teil dieses Workflows, den keine Vorlage löst, und genau dort geht die Zeit hin. ScreenSnap Pro erledigt die ganze Runde in einem Durchgang auf Mac und Windows: Bereichsaufnahme, 15 Annotationswerkzeuge inklusive Pfeilen, Text, Unschärfe und Verpixelung für Kundendaten sowie ein Zähler-Werkzeug für nummerierte Schritte, dazu Screen-zu-GIF-Aufnahme ohne Video-Konvertierung dazwischen. Der optionale Cloud-Upload gibt dir einen Link zurück, den du direkt in die Notes setzt. Das kostet einmalig 39 $ statt einer weiteren monatlichen Position, was zählt, wenn du das Werkzeug einmal pro Release öffnest.

Wenn dein In-App-Changelog-Widget oder deine E-Mail-Plattform eine Größengrenze hat, schick das GIF vorher durch unseren kostenlosen GIF-Compressor. Die Bildrate senken und eine Sekunde am Ende abschneiden bringt eine 6-MB-Aufnahme meist unter 2 MB, ohne sichtbaren Qualitätsverlust.

Wo du veröffentlichst und wie du verteilst

Eine Release Note, mehrere Ziele. Jedes Ziel will eine andere Länge, und genau dafür gibt es die drei Vorlagen.

In-App-Fenster oder "Neu"-Panel

Die höchste Leserate von allen Kanälen, weil der Leser schon in deinem Produkt ist. Nimm die kurze Karten-Vorlage: eine Änderung, ein Visual, ein Link zu den vollen Notes. Zeig sie einmal pro Nutzer und Release und mach sie schließbar.

Eine dauerhafte Doku-Seite

Deine kanonische Version. Neuestes Release oben, ein Ankerlink pro Version, damit der Support jemanden direkt auf #3-4-0 schicken kann. Das ist die Seite, die in der Suche rankt und von der du überall sonst aus verlinkst.

GitHub Releases

Wenn du Code auslieferst, ist der Release-Body der erste Ort, an dem Entwickler schauen. GitHubs Doku zum Verwalten von Releases in einem Repository erklärt Tags und die automatisch erzeugten Notes, die einen brauchbaren ersten Entwurf aus gemergten Pull Requests bauen. Behandle diesen Entwurf als Rohmaterial: er listet Commits, nicht Änderungen, die ein Nutzer versteht.

E-Mail

Der beste Kanal für Breaking Changes und Abkündigungen, weil du Leute erreichen musst, die gerade nicht eingeloggt sind. Halte es bei der Zusammenfassung plus den ein oder zwei Punkten, die Handeln erfordern, und verlinke dann raus. Jedes Bild muss gehostet sein, und jedes Bild braucht Alt-Text, weil ein guter Teil der Empfänger Bilder standardmäßig blockiert.

Eine Ankündigung im Team-Chat

Erst intern. Poste die Notes in einem eigenen Kanal, bevor die Kundenversion rausgeht, damit Support und Sales nie von einer Frage zu einer Funktion überrascht werden, die sie noch nicht gesehen haben. Auch hier verdient sich das GIF seinen Platz: ein Support-Mitarbeiter, der einen 4-Sekunden-Clip gesehen hat, kann ein Ticket dazu sofort beantworten.

Reine Text-Release-Notes werden auf jedem dieser Kanäle nur überflogen. Ein einzelner annotierter Screenshot pro Funktion ist das, was das Scrollen stoppt.

Fehlersuche: warum niemand deine Release Notes liest

Wenn du regelmäßig veröffentlichst und trotzdem niemand reagiert, ist es meist einer dieser sechs Punkte.

Es ist eine Textwand

Zwölf Punkte ohne Überschriften, ohne Fettung und ohne Bilder lesen sich als ein grauer Block. Setz die Abschnittsüberschriften aus der Vorlage ein und dann ein Visual in den Funktionsteil. Allein die Struktur holt den größten Teil der verlorenen Aufmerksamkeit zurück.

Bilder brechen in E-Mails

Bilder aus einem internen Wiki, ein S3-Bucket mit falschen Rechten oder ein Link, der Login braucht: alles rendert im Postfach als kaputtes Symbol. Teste die Mail in mindestens einem Desktop- und einem Mobile-Client mit blockierten Bildern und gib jedem Bild echten Alt-Text, damit auch der blockierte Zustand etwas sagt.

GIFs sind zu schwer für das Widget

In-App-Changelog-Widgets und E-Mail-Plattformen haben Größengrenzen, und eine 30-Sekunden-Aufnahme reißt sie. Die Lösung liegt vorne: weniger aufnehmen, dann komprimieren. Sechs Sekunden bei mittlerer Bildrate reichen fast immer.

Screenshots veralten nach einer UI-Änderung

Eine Release Note vom März, die eine Toolbar zeigt, die es nicht mehr gibt, führt Leute aktiv in die Irre. Versioniere deine Assets mit dem Release: benenne die Datei nach der Version, behalte sie und überschreibe nie ein altes Bild mit einem neuen. Alte Notes sollen so aussehen, wie das Produkt damals aussah.

Die Bildgrößen sind ungleich

Drei Screenshots in drei Breiten auf einer Seite sehen schlampig aus. Leser lesen das als "dieses Team achtet nicht auf Details", lange bevor sie merken, warum. Leg die Aufnahmegröße in deinem Prozessdokument fest und denk nicht mehr darüber nach.

Du veröffentlichst nur auf einem Kanal

Nur Doku-Seite heißt: Entwickler sehen es, Kunden nicht. Nur In-App heißt: ausgeloggte Kunden erfahren nie von der Abkündigung, die sie betrifft. Nimm mindestens zwei Kanäle, einen Push und einen dauerhaften.

Das Muster hinter allen sechs Punkten: Release Notes scheitern an der Produktion, nicht am Schreiben. Sobald das Format eine Vorlage ist und der visuelle Schritt Routine, dauert die ganze Sache fünfzehn Minuten.

Release-Notes-Checkliste

Geh das vor dem Veröffentlichen durch. Es kostet zwei Minuten.

• [ ] Die Versionsnummer passt zum Tag, den du wirklich ausgeliefert hast
• [ ] Ein Datum ist da, im Format JJJJ-MM-TT
• [ ] Die Zusammenfassung hat ein bis zwei Sätze und nennt die wichtigste Änderung
• [ ] Jeder Punkt enthält genau eine Änderung
• [ ] Jeder Fix beschreibt das Symptom, nicht den Code
• [ ] Keine internen Ticket-IDs oder Komponentennamen in der Kundenversion
• [ ] "Verschiedene Verbesserungen" kommt nirgends vor
• [ ] Jede neue Funktion hat einen annotierten Screenshot oder ein kurzes GIF
• [ ] Jedes Bild ist gehostet, gleich groß und hat Alt-Text
• [ ] Kundendaten in Screenshots sind unscharf oder verpixelt
• [ ] Der Abschnitt "Bekannte Probleme" nennt Workarounds oder ist gelöscht
• [ ] Abkündigungen haben ein Datum
• [ ] Breaking Changes haben nummerierte Schritte und eine Prüfmöglichkeit
• [ ] Links funktionieren, auch der Link von der In-App-Karte zu den vollen Notes
• [ ] Auf mindestens zwei Kanälen veröffentlicht

Sobald diese Checkliste dich nicht mehr überrascht, hol sie in den schriftlichen Prozess deines Teams. Wer die Release Note besitzt, sollte dort stehen, genau wie jede andere wiederkehrende Aufgabe in eine Vorlage für Arbeitsanweisungen gehört. Teams, die Zuständigkeiten über mehrere wiederkehrende Dokumente festhalten, finden das größere Muster in unserem Guide zur Prozessdokumentation.

Häufig gestellte Fragen

Was gehört in eine Release Notes Vorlage?

Mindestens: Produktname und Versionsnummer, Release-Datum, eine Zusammenfassung aus ein bis zwei Sätzen, neue Funktionen, Verbesserungen, Bugfixes und bekannte Probleme. Ergänze Abkündigungen und Breaking Changes mit nummerierten Upgrade-Schritten, sobald ein Release bestehende Setups betrifft. Eine Danke-Zeile ist optional und billig. Lösche jeden leeren Abschnitt, statt eine leere Überschrift stehen zu lassen.

Was ist der Unterschied zwischen Release Notes und einem Changelog?

Ein Changelog ist eine vollständige Liste aller Änderungen, die nur wächst, meist eine CHANGELOG.md im Repo, geschrieben für Entwickler. Release Notes sind kuratiert: du wählst die Änderungen aus, die für deine Zielgruppe zählen, schreibst sie in klarer Sprache und lässt Dinge absichtlich weg. Viele Teams pflegen beides und bauen die Release Notes aus dem Changelog, statt zwei getrennte Sammlungen von Hand zu führen.

Wer schreibt Release Notes?

Den Rohtext schreibt der Entwickler, der die Änderung ausgeliefert hat, weil nur er genau weiß, was sich geändert hat. Übersetzt wird er von jemand anderem, meist Product Manager, Produktmarketing oder Technical Writer. Diese Teilung vermeidet beide Fallen. Schreibt Engineering die Endfassung, stecken die Notes voller Komponentennamen. Schreibt Marketing sie allein, wird die Änderung falsch beschrieben.

Wie lang sollten Release Notes sein?

So lang wie das Release, nicht länger. Ein Hotfix ist eine Zeile. Ein Patch sind drei bis sechs Punkte. Ein Feature-Release ist eine halbe bis zwei Seiten, Visuals eingerechnet. Die In-App-Karte hat zwei bis vier Zeilen, unabhängig von der Release-Größe. Länge ist eine Folge des Umfangs, nie ein Ziel.

Sollten Release Notes in Word, Markdown oder in der App stehen?

Schreib die kanonische Version in Markdown. Die kopiert sich sauber in ein GitHub Release, rendert auf einer Doku-Seite, wird zu HTML für E-Mail und liegt neben dem Code in der Versionskontrolle. Word-Dateien lohnen sich nur, wenn ein Kundenvertrag oder ein geprüfter Prozess ein signiertes, seitenweises Dokument braucht. In-App ist ein Verteilkanal, nicht die Quelle: leite die Karte aus dem Markdown ab.

Wie oft solltest du Release Notes veröffentlichen?

Für jedes Release, das ein Nutzer merken könnte, auch wenn das mehrere pro Woche sind. Verlässlich sein zählt mehr als häufig sein: Leser, die lernen, dass jede Version eine Note hat, schauen nach. Leser, die Lücken finden, hören auf zu schauen. Stille Releases sind der schnellste Weg, Leute daran zu gewöhnen, die Notes-Seite zu ignorieren.

Die Kurzfassung

Die Struktur ist die leichte Hälfte, und die hast du jetzt in drei Größen. Die Hälfte, die wirklich Zeit kostet, ist das Visual: ein annotierter Screenshot pro Funktion, ein kurzes GIF für alles Interaktive, dieselbe Bildbreite in jedem Release und Kundendaten unscharf, bevor das Bild deinen Rechner verlässt.

Wenn Aufnahme und Annotation der Engpass in deinem Release-Prozess sind, deckt ScreenSnap Pro das in einem Durchgang auf Mac und Windows ab, einmalig für 39 $ und ohne Abo.