Ein Changelog-Eintrag beschreibt eine bestätigte Funktionsänderung mit Versionskennung, wirksamem Datum, betroffenem Nutzerkreis und erforderlicher Aktion. Die Vorlage betrifft eine bereits bereitgestellte Funktion, keine erste Produkteinführung.
Fakten für eine Änderung sammeln
Lassen Sie Funktionsname, Versionskennung, tatsächlichen Bereitstellungszeitpunkt und betroffene Nutzer vom zuständigen Produktteam bestätigen. Ein geplanter Termin ist kein Wirksamkeitsdatum. Bei eingeschränktem Zugang nennen Sie die betroffene Gruppe.
Ein internes Ticket kann Entscheidungen dokumentieren, ersetzt aber keine verständliche Funktionsbeschreibung. Der Eintrag muss ohne interne Notizen nachvollziehbar sein.
Version und Datum korrekt angeben
Verwenden Sie die tatsächlich eingesetzte Versionskennung. Erfinden Sie keine Nummer für den Artikel. Nutzt das Produkt SemVer, gelten dessen Regeln für die deklarierte öffentliche API. Andere Nummerierungssysteme können eine andere Bedeutung haben.
Schreiben Sie das Datum eindeutig, etwa YYYY-MM-DD; bei relevanter Uhrzeit ergänzen Sie die Zeitzone. Das Schreibdatum kann abweichen. Bei gestaffelter Bereitstellung nennen Sie Beginn und aktuellen Umfang statt Zugriff für alle zu suggerieren.
Vorher und nachher beschreiben
Erklären Sie das beobachtbare Verhalten vor und nach der Änderung. Nennen Sie Nutzerkreis, Grenzen und nötige Schritte. Ist keine Aktion erforderlich, sagen Sie das ausdrücklich.
Unbestätigte Vorteile gehören nicht hinein. Eine Änderung an Filtern beweist weder mehr Umsatz noch eine bestimmte Zeitersparnis. Preis- und Abrechnungsregeln bleiben in der dafür vorgesehenen Dokumentation.
Beispiel für einen Eintrag
Dieses fiktive Beispiel beschreibt keine Semly-Veröffentlichung.
- Funktion: Filtern einer Dokumentliste.
- Version: 2.4.1 nach dem Nummerierungssystem des Beispielprodukts.
- Wirksam ab: 2026-10-12.
- Vorher: Ein zweiter Filter entfernte den ersten.
- Nachher: Beide ausgewählten Filter werden gemeinsam angewendet.
- Umfang: Nutzer der Dokumentliste in Version 2.4.1.
- Aktion: Die geöffnete Liste nach dem Update neu laden.
- Grenze: Gespeicherte Filtervorlagen bleiben unverändert.
Die Grenze verhindert falsche Annahmen über Vorlagen. Ergänzen Sie im echten Eintrag einen geprüften Dokumentationslink. Fehlt eine Anleitung, erklären Sie den Schritt, ohne eine URL zu erfinden.
Vor dem Speichern prüfen
Vergleichen Sie Version, Datum, Umfang und Verhalten mit der Bestätigung des Produktteams. Testen Sie die Aktion und den Dokumentationslink. Ein Leser ohne Ticketkenntnis muss erkennen können, was sich wann verändert hat.
Mehrere unabhängige Änderungen erhalten getrennte Einträge innerhalb der Version. Für dieselbe Änderung sind keine mehrfachen Artikel nötig.
Bedeutung in Übersetzungen bewahren
Übersetzungen behalten Kennung, Zeitpunkt, Nutzerkreis und Grenzen. Eine neue Sprache bestätigt keinen zusätzlichen Markt. Landesunterschiede müssen ausdrücklich belegt sein.
Bei einer redaktionellen Korrektur bleibt das echte Bereitstellungsdatum erhalten; kennzeichnen Sie die Textkorrektur separat. Sie ist keine neue Bereitstellung.
Quelle zur Versionsnummerierung
SemVer bezieht sich auf eine deklarierte öffentliche API. Es ist kein verpflichtendes Nummerierungssystem für jede SaaS-Anwendung.
