Blogpost-Versionierung: Revisionen ermöglichen, ohne frühere Fassungen zu verlieren

[chsteiner]

Worum es geht

Blogposts sollen überarbeitbar werden, ohne dass die frühere Fassung verschwindet. Zwei Gründe: Ältere Posts sollen revidiert und verbessert werden können, und die Entwicklung eines Textes soll auf der Seite sichtbar sein.

Ein erster Anlauf dazu liegt in a4dc576..f74dceb und wurde mit df6acfb zurückgenommen. Die Commits sind als Referenz noch in der Historie.

Warum der erste Anlauf zurückgenommen wurde

Der Ansatz war eine zusätzliche Datei pro Fassung: Asymmetric-Amplification-v1.md als Archiv neben dem kanonischen Slug, der die aktuelle Version trägt.

Das skaliert nicht. Bei mehreren versionierten Posts liegen im flachen src/content/blog/ zwei bis drei Dateien pro Text, die im Dateinamen kaum unterscheidbar sind. Beim Arbeiten im Ordner ist nicht mehr erkennbar, welche Datei live ist, welche ein Entwurf und welche ein Archiv. Genau das ist passiert.

Dazu kam, dass die Redaktions-Wissensbasis unter knowledge/ mitlief und damit Planungsmaterial für einen unveröffentlichten Text öffentlich im Site-Repo lag.

Randbedingungen im aktuellen Setup

• Der Loader in src/content.config.ts ist flach (pattern: '*.md'). Unterordner unter src/content/blog/ werden derzeit gar nicht geladen.
• generateId erhält den Dateinamen exakt. Der Kommentar dort hält den Erhaltungs-Constraint aus der Migration fest: die URLs /excellence/blog/<Dateiname>/ müssen stabil bleiben. Jede Lösung muss die bestehenden neun Post-URLs unverändert lassen.
• Das Schema kennt bereits last_modified_at. Es fließt in dateModified des JSON-LD (BlogPost.astro:67), wird im sichtbaren Post aber nirgends ausgegeben. Die Post-Metazeile (BlogPost.astro:199) zeigt nur das Publikationsdatum.
• Der APA-Zitiervorschlag baut ausschließlich auf d.date auf und kennt keine Versionen. Wenn eine überarbeitete Fassung unter derselben URL liegt, zeigt die Zitation weiterhin das ursprüngliche Datum, was bei zitierten Posts falsch ist.

Vorschlag

Historie aus Git bauen statt Fassungen als Dateien mitschleppen. Jede frühere Version steht bereits vollständig in der Repo-Historie. Ein Build-Schritt kann git log für die jeweilige Datei auslesen und daraus eine Versionsliste erzeugen. Damit kann die Dokumentation der Textentwicklung nicht mehr vom tatsächlichen Stand abweichen, und der Content-Ordner bleibt bei einer Datei pro Post.

Zu beachten: Der Checkout im Deploy-Workflow (.github/workflows/deploy.yml:27) ist actions/checkout@v4 ohne fetch-depth, also flach. Für die Historie muss dort fetch-depth: 0 gesetzt werden, sonst funktioniert das lokal und bricht im Build.

Falls doch Dateien pro Fassung gewünscht sind, dann als Unterordner pro Post (Asymmetric-Amplification/index.md plus revisions/2026-02-09.md), nicht als Geschwisterdateien mit Suffix. Das erfordert eine Loader-Anpassung auf **/*.md mit angepasstem generateId, damit die bestehenden URLs erhalten bleiben.

Unabhängig von der Variante braucht es im Frontmatter ein gepflegtes last_modified_at und dessen Anzeige im Post, plus eine Zitation, die die abgerufene Fassung benennt.

Offene Entscheidungen

• Git-generierte Historie oder Dateien pro Fassung.
• Werden alle Commits einer Datei als Versionen gezeigt (auch Tippfehler-Korrekturen) oder nur markierte Fassungen, etwa über Tags oder einen Frontmatter-Eintrag.
• Bekommt eine frühere Fassung eine eigene zitierbare URL oder nur eine Ansicht im Kontext des aktuellen Posts.
• Was passiert mit dem bestehenden APA-Zitiervorschlag bei revidierten Posts.

Aus dem ersten Anlauf übernehmenswert

633d60d hat unveröffentlichte Entwürfe nur im Dev-Modus gerendert:

const posts = await getCollection('blog', ({ data }) => import.meta.env.DEV || data.published);

Das ist unabhängig von der Versionierung nützlich, weil published: false sonst bedeutet, dass ein Entwurf lokal gar nicht ansehbar ist. Kann als eigener kleiner PR vorgezogen werden.