Release-Notes-Beispiele für jede Art von Änderung

Die besten Release-Notes-Beispiele sind kurz, nennen, wer betroffen ist, und sagen, was als Nächstes zu tun ist. Unten steht je ein Beispiel für jede Art von Änderung, die ihr ausliefern werdet, mit dem Grund, warum es funktioniert. So könnt ihr die Form übernehmen und eure eigenen Fakten einsetzen.

Jedes Beispiel ist erfunden, für eine fiktive Rechnungs-App namens Tidepool.

Was haben gute Release-Notes-Beispiele gemeinsam?

Sie sagen den Nutzerinnen, was sich geändert hat und was sie dazu gegebenenfalls tun müssen, in deren eigenen Worten. Jede Art von Änderung hat eine andere Aufgabe, also wechselt die Form von Fall zu Fall.

Wie sieht eine gute Note zu einem neuen Feature aus?

Eine gute Feature-Note beginnt damit, was die Leserin jetzt tun kann, und nennt die Tarife oder Rollen, die es bekommen. Die Umsetzung lässt sie weg.

Rechnungen in der Sprache der Kundin versenden. Du kannst jetzt für jede Kundin eine Sprache wählen, und ihre Rechnungen, Erinnerungen und die Zahlungsseite folgen ihr. Französisch, Deutsch, Spanisch und Portugiesisch gibt es in allen Tarifen. Stelle sie auf der Kundenseite unter Rechnungseinstellungen ein.

Die Überschrift ist ein Satz, den die Leserin laut sagen würde, und der Text nennt Umfang und Ort. Wer nur die fette Zeile überfliegt, weiß trotzdem, was ausgeliefert wurde. Die breitere Methode steht in Wie man Release Notes schreibt.

Wie sieht eine gute Note zu einer Verbesserung aus?

Eine Verbesserungs-Note beschreibt eine Änderung, die die Leserin spürt, und nennt eine gemessene Zahl, wenn es eine gibt. Ohne Zahl sagt, was die Leserin nicht mehr tun muss.

Die Rechnungsliste lädt etwa dreimal schneller. Konten mit über 5.000 Rechnungen warteten bisher etwa neun Sekunden auf die Liste. Jetzt öffnet sie in etwa drei. Keine Aktion nötig.

“Performance-Verbesserungen” sagt der Leserin nichts, während neun Sekunden gegen drei eine Aussage sind, die sie am Montagmorgen nachprüfen kann. Das abschließende “Keine Aktion nötig” beantwortet die Frage, die jede Leserin hat.

Wie sieht eine gute Bugfix-Note aus?

Eine Bugfix-Note beschreibt das Symptom, das die Nutzerin sah, nicht die Ursache im Code, und sagt, ob sie etwas wiederholen muss. Fixes, die niemand bemerkt hat, können in die Liste ganz unten.

Behoben: Erinnerungs-E-Mails wurden am Fälligkeitstag doppelt versendet. Manche Kundinnen erhielten zwei identische Erinnerungen, wenn ihre Rechnung am letzten Tag eines Monats fällig war. Das ist behoben. Bereits versendete Erinnerungen sind nicht betroffen, und niemand muss etwas erneut senden.

Die Überschrift beginnt mit “Behoben”, sodass jemand beim Überfliegen sie sofort einsortieren kann, und die eigentliche Bedingung (der letzte Tag des Monats) folgt unmittelbar.

Wie schreibt man Release Notes zu einem Breaking Change?

Eine Breaking-Change-Note beginnt mit dem Datum und der betroffenen Gruppe und liefert die Migration im selben Eintrag. Sie steht in den Release Notes ganz vorn, weil sie der eine Eintrag ist, den eine Leserin nicht verpassen darf.

Webhook-Signaturen werden am 1. Dezember 2026 Pflicht. Ab diesem Datum sendet Tidepool keine unsignierten Webhook-Payloads mehr. Betroffen ist, wer Webhooks empfängt, ohne den Header Tidepool-Signature zu prüfen. Zur Migration prüfst du den Header mit dem Secret unter Einstellungen, Entwickler. Prüfst du Signaturen bereits, ist keine Aktion nötig.

Das Datum steht in der Überschrift und überlebt so das Überfliegen. Die betroffene Gruppe wird über das benannt, was sie tut, und der letzte Satz entlässt alle, die schon in Ordnung sind, was die Support-Last senkt. Der Leitfaden zu Breaking Changes behandelt, wie ihr entscheidet, ob eine Änderung dazuzählt.

Wie sieht eine Note zu einem Sicherheitsfix aus?

Eine Sicherheits-Note sagt, was offenlag, ob jemand es ausgenutzt hat, wer betroffen ist und was zu tun ist. Haltet sie sachlich und ruhig.

Sicherheit: Links zum Zurücksetzen des Passworts konnten wiederverwendet werden. Zwischen dem 3. und 17. September 2026 blieb ein Link zum Zurücksetzen des Passworts nach der ersten Nutzung gültig. Wir haben keine Hinweise gefunden, dass dies ausgenutzt wurde. Es ist behoben, und alle offenen Links wurden ungültig gemacht. Hast du in diesem Zeitraum ein Zurücksetzen angefordert, fordere einen neuen Link an.

Der genaue Zeitraum lässt die Leserin ihre eigene Betroffenheit beurteilen, und der Satz zur Ausnutzung beantwortet die erste Frage, die jede stellt. “Ein mögliches Problem” liest sich wie Verschleierung, also nennt, was ihr wisst.

Wie schreibt man eine Deprecation-Mitteilung?

Eine Deprecation-Mitteilung nennt, was entfernt wird, gibt ein festes Enddatum und verweist auf den Ersatz.

Der Endpunkt v1 für Rechnungen ist veraltet und endet am 1. März 2027. GET /v1/invoices funktioniert bis zum 1. März 2027 weiter und liefert danach 410 Gone. Nutze GET /v2/invoices, das dieselben Felder plus currency liefert. Antworten von v1 enthalten jetzt einen Sunset-Header mit dem Enddatum. Eine Migrationsanleitung im Vergleich steht in der Doku.

Der Endpunktname steht in der Überschrift, weil die Betroffenen danach suchen, und der Ersatz steht neben der Entfernung. Der Sunset-Header zeigt Entwicklerinnen, welche Aufrufe noch die alte Version nutzen. Die ausführlichere Behandlung steht in API abkündigen.

Wie sieht ein App-Store-Text für ein Release aus?

Ein App-Store-Text besteht aus zwei oder drei schlichten Sätzen, weil die meisten nur die erste Zeile lesen. Beginnt mit der Änderung, die eine Nutzerin bemerken würde.

Scanne einen Papierbeleg, und Tidepool trägt Betrag, Datum und Anbieter ein. Der Dunkelmodus folgt jetzt der Einstellung deines Handys. Außerdem haben wir einen Absturz behoben, der beim Öffnen einer Rechnung aus einer Benachrichtigung auftrat.

Die nützlichste Änderung kommt zuerst, und der Fix benennt die Situation, in der es abstürzte. Es gibt keine Versionsnummer und kein “Fehlerbehebungen und Verbesserungen”. Release Notes für mobile Apps behandelt die Store-spezifischen Regeln.

Was sollte eine interne Release-Notiz enthalten?

Eine interne Notiz ist die Fassung für Support und Vertrieb. Sie ergänzt, was die öffentliche Note weglässt: was gesagt werden soll und was man nicht versprechen darf.

Mehrsprachige Rechnungen heute ausgeliefert (alle Tarife). Support: Kundinnen stellen die Sprache unter Rechnungseinstellungen ein, und bestehende Rechnungen behalten ihre ursprüngliche Sprache. Italienisch gibt es noch nicht. Vertrieb: Das gilt für jeden Tarif, positioniert es also nicht als Upgrade.

Jede Zielgruppe bekommt ihre eigene beschriftete Zeile, und die Notiz zieht die Grenze (“Italienisch gibt es noch nicht”), bevor eine Kundin fragt. Der Artikel zu internen Release Notes behandelt Format und Kanäle.

Wie sieht eine schlechte Release Note aus, neu geschrieben?

Eine schlechte Release Note listet auf, was das Team getan hat, statt dessen, was die Leserin bekommt. Behebt das, indem ihr das Ergebnis nach vorn zieht und das interne Vokabular streicht.

Vorher:

v3.8.1 Erinnerungs-Scheduler refaktoriert. Race Condition in ReminderJob behoben. bull auf 4.12 aktualisiert. Diverse Verbesserungen.

Nachher:

Erinnerungs-E-Mails werden nicht mehr doppelt versendet. Kundinnen mit einer Rechnung, die am letzten Tag eines Monats fällig war, konnten zwei Erinnerungen bekommen. Das ist behoben, und bereits versendete Erinnerungen müssen nicht erneut gesendet werden. Keine Aktion nötig.

Auch in 3.8.1: bull auf 4.12 aktualisiert.

Das Abhängigkeits-Update rutschte in eine Fußzeile, und die Race Condition wurde zu einem Symptom, das eine Kundin wiedererkennen würde.

Wie halte ich Release Notes über mehrere Releases hinweg konsistent?

Entwerft jeden Eintrag, wenn die Änderung gemerged wird, und lasst ihn von einem Menschen freigeben, bevor er ausgeliefert wird.

Changeloop arbeitet so: Es entwirft mit KI aus jedem gemergten Pull Request einen Eintrag und hält ihn zur Freigabe durch einen Menschen zurück. Im Freigabeschritt wendet eine Redakteurin die obigen Regeln an. Um zuerst das Format zu klären, startet mit der Release-Notes-Vorlage und schaut in die Changelog-Beispiele, wie fertige Seiten aussehen.

FAQ

Was sind neue Release Notes? Neue Release Notes sind die Nachricht, die mit dem neuesten Release eines Produkts veröffentlicht wird und beschreibt, was sich geändert hat und was Nutzerinnen tun müssen. Sie decken Features, Verbesserungen, Fixes und Breaking Changes ab.

Was ist der Unterschied zwischen einer Release Note und einem Changelog? Der Changelog hält alles fest, für alle, die den ganzen Verlauf wollen. Eine Release Note wählt daraus aus: ein Release, geschrieben für die Leserinnen, die entscheiden, ob es sie betrifft. Der ausführliche Vergleich steht in Changelog vs. Release Notes.

Was bedeutet Release Notes? Release Notes sagen Nutzerinnen, was sich in einem Release geändert hat. Der Begriff umfasst alles, was erklärt, was ausgeliefert wurde, vom “Neu”-Text im App Store bis zu einer Seite auf der Firmenwebsite.

Wie lang sollte jeder Eintrag in den Release Notes sein? Zwei bis vier Sätze reichen für die meisten Einträge: das Ergebnis, wer betroffen ist und was zu tun ist. Ein Breaking Change oder ein Sicherheitsfix darf länger sein, weil er ein Datum oder eine Migration braucht.

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