Was gelesen wird

Der Parser liest ein Changelog als flachen Lauf von Überschriften und entscheidet, was jede davon ist. Nichts wird konfiguriert: Die Eingabe ist die Form der Datei selbst.

#Eine Release-Überschrift

Eine Überschrift ist ein Release, wenn — mit jedem Link auf seinen sichtbaren Text reduziert — übrig bleibt: eine Version, optional gefolgt von einem Datum in Klammern.

## [1.4.0](https://github.com/acme/app/compare/v1.3.0...v1.4.0) (2026-02-01)
### [1.4.1](https://github.com/acme/app/compare/v1.4.0...v1.4.1) (2026-02-03)
## 1.4.0 (2026-02-01)
## v2.0.0

Alle vier werden gelesen. Die ersten beiden sind, was release-please schreibt — ein Minor-Release auf ## und ein Patch auf ### — und die letzten beiden sind eine handgepflegte Datei. Die Ebene ist nicht Teil des Tests, und genau das lässt beide Formen durch.

Die Ebene wird am Körper abgelesen statt angenommen, aus demselben Grund: release-please schreibt ein Patch-Release auf ### und seine Gruppen ebenfalls auf ###, „die flachste Überschrift in diesem Release“ ist also die einzige Regel, die beides liest.

#Eine Gruppenüberschrift

Jede Überschrift unterhalb der Ebene des Releases ist eine Gruppe, und ihr Name ist der der Datei — wörtlich, unübersetzt, ohne feste Taxonomie dahinter.

### Features
### Bug Fixes

release-please schreibt diese beiden, changesets schreibt seinen eigenen Satz, Keep a Changelog einen weiteren, und jedes davon schreibt sie in der Sprache, in der das Projekt gepflegt wird. Eine Ebene, die sie auf eine feste Liste abbildete, würde bei der ersten Überschrift, die sie nicht kennt, still scheitern — die Filter auf der Übersicht werden also aus dem gebaut, was aus der Datei kam, und ein auf Deutsch geschriebenes Changelog filtert auf Deutsch, ohne dass etwas konfiguriert wäre.

Das Abzeichen neben einer Gruppe zählt ihre Listenpunkte der obersten Ebene. Eine Überschrift innerhalb eines Code-Blocks ist Text und keine Überschrift, und ein Zaun schließt nur auf seine eigene Art.

#Der Titel und die Präambel

Das erste # in der Datei ist, wenn kein Release davor kam, der eigene Titel der Datei und fällt weg — die Seite zieht ihre Überschrift aus title, ihn zu behalten wäre also ein zweites <h1>.

Nur dieses eine, und nur vor dem ersten Release. Jedes # fallen zu lassen liest sich richtig auf der Datei, die release-please schreibt, wo es genau eines gibt — und ist stiller Inhaltsverlust bei einem handgepflegten Changelog, das seine Releases auf der obersten Ebene führt.

Was sonst vor dem ersten Release steht, bleibt, als eigene Einleitung der Übersicht.

#Eine Überschrift, die fast ein Release ist

Die Toleranz oben hat eine stille Kante: Eine Überschrift, die der Release-Test nicht trifft, ist Prosa, ihre Zeilen fallen also in das Release darüber, und das Release, das sie sein sollte, wird nie eine Seite. Nichts an der gerenderten Site würde das sagen.

Also sagt es der Build. Eine Überschrift, die mit einer Zahl mit Punkt beginnt, aber nicht gelesen wird — ## 1.4 (Feb 2024) oder die Keep-a-Changelog-Form ## [1.2.3] - 2024-01-01 — wird im Build-Bericht gemeldet, mit der Zeile und der Form, die funktioniert.

Es ist eine Warnung und kein Fehler, aus dem Grund, aus dem jeder Inhaltsbefund einer ist: Die Site rendert, und ein Changelog, das diese Ebene nicht geschrieben hat, ist nicht ihres, es abzulehnen. Siehe Was der Build prüft.

#Die URL, unter der ein Release liegt

Die Version, mit einem v davor, wo sie mit einer Ziffer beginnt.

/releases/v1.4.0

Das v ist keine Verzierung. Content liest einen Dateinamen aus nur Ziffern und Punkten als Version und hört auf, ihn zu verfeinern — was das Ordnungspräfix in der Adresse ließe: /releases/01.0.2.0. Mit dem v wird das Präfix entfernt wie überall sonst, und das Segment entspricht dem Tag, unter dem das Release geschnitten wurde.