Granularität
Eine Seite pro Release, oder die Datei als die eine Seite, als die sie geschrieben wurde.
granularity ist die eine Option, die der Typ liest. Sie nimmt split — den
Standard — oder flat, und der Unterschied reicht weiter als die Seitenzahl.
{
type: 'changelog',
path: 'CHANGELOG.md',
label: 'Changelog',
options: { granularity: 'flat' }
}
split — eine Seite pro Release
Der Standard, und wofür eine Release-Historie da ist. Jedes Release wird zu einer eigenen Seite unter einer generierten Übersicht, was vier Dinge kauft, die eine einzelne Seite nicht haben kann:
- einen Deep Link auf ein Release, und auf eine Gruppe darin;
- einen Suchtreffer, der das Release ist und nicht die ganze Datei;
- einen Feed-Eintrag pro Release, sobald
feed.pathdie Sektion benennt; - einen
llms.txt-Eintrag pro Release, sodass ein Modell, das fragt, was sich in2.1.0geändert hat, dieses Release bekommt und nicht vierhundert Kilobyte Historie.
Die Übersicht ist eine Zeitleiste — jedes Release, neueste zuerst, mit seinem
Datum und den Arten von Änderung daneben, filterbar nach diesen Arten. Die
Einträge selbst bleiben auf den Release-Seiten: Sie auf der Übersicht zu
wiederholen würde das ganze Changelog doppelt in den Suchindex, in
llms-full.txt und in den Feed legen.
Getrennte Seiten rendern in einem eigenen Layout: die Releases in der Seitenleiste, eine auf ein Maß begrenzte Lesespalte und eine Inhaltsspalte, die die Gruppen listet. Siehe Komponenten.
flat — die Datei, wie sie ist
Eine Seite, die die Datei hält, wie sie geschrieben wurde. Für ein Projekt, das sein Changelog einfach gezeigt haben will.
Ein flaches Changelog ist eine gewöhnliche Doku-Seite und behält das Doku-Gerüst — die Prosa-Seitenleiste, den Brotkrumenpfad und ein Inhaltsverzeichnis, das die Releases listet, was eine lange Datei genau will. Deshalb wird die Layout-Frage aus den Optionen der Deklaration beantwortet und nicht vom Typ festgelegt: Derselbe Typ erzeugt zwei verschiedene Dinge.
Nichts wird umgeschrieben außer dem Titel. Das eigene # Changelog der Datei
geht, weil die Seite ihre Überschrift aus title zieht und ein zweites <h1> im
Körper sowohl ein Duplikat als auch ein Barrierefreiheits-Befund ist. Jede
Release-Überschrift bleibt genau dort, wo das Release-Werkzeug sie hingeschrieben
hat — was „unverändert“ heißen muss, sonst ist der Modus nicht die Notluke, für
die es ihn gibt.
Wozu greifen
| Du willst | Nimm |
|---|---|
| Eine Release-Historie, durch die Leser navigieren und verlinken | split |
Einen Feed, oder Einträge pro Release in llms.txt | split |
| Die Datei gezeigt wie geschrieben, ohne erfundene URLs | flat |
granularty, oder eine Granularität, die keine der beiden ist, hält den Build an
und nennt den Schlüssel oder Wert, den er nicht erkannt hat. Ein Zeichen neben dem
Schlüssel, der funktioniert, ist eine Site, die still den Standard bekommt statt
dessen, was sie konfiguriert hat, und der Build ist der letzte Ort, der das sagen
kann.