Versionen und Kompatibilität
DiGeKo besteht aus getrennten Repositories für App, CMS und Dokumentation. App und CMS werden unabhängig versioniert. Entscheidend für Installation und Nachnutzung ist deshalb die ausdrücklich getestete Kombination und nicht eine künstlich identische Versionsnummer aller Komponenten.
Die aktuell empfohlene Kombination wird auf dieser Seite mit Links zu den jeweiligen GitLab Releases und dem dauerhaft verfügbaren Compatibility- Datenstand veröffentlicht.
Komponenten und Release-Tags
App und CMS verwenden SemVer-Tags wie v0.2.0. Ein Tag bezeichnet einen
unveränderlichen, geprüften Stand genau dieses Repositories. Nur eine
tatsächlich geänderte Komponente erhält eine neue Version. Unterschiedliche
Versionsnummern sind daher normal, zum Beispiel:
CMS v0.2.0
App v0.1.2
Starterdaten Schema-Generation 2Vor Version 1.0.0 kennzeichnet eine neue Minor-Version üblicherweise eine
größere Funktion oder mögliche Vertragsänderung. Patch-Versionen sind für
abwärtskompatible Fehlerbehebungen vorgesehen. Öffentliche Vorabstände können
als v0.2.0-beta.1 oder v0.2.0-rc.1 erscheinen.
Die Dokumentation ist keine Laufzeitabhängigkeit von App oder CMS. Sie beschreibt grundsätzlich die aktuelle Empfehlung; ein eigener Docs-Tag ist nur für einen bewusst reproduzierbar markierten Dokumentationsstand erforderlich.
Aktuell empfohlene Kombination
Diese Seite ist die zentrale, bewegliche Quelle für die aktuelle Empfehlung. Die READMEs der Komponenten verlinken hierher und enthalten bewusst keine Kopie der jeweils aktuellen Versionsnummern.
| Bestandteil | Empfohlener Stand | Gemeinsam getestet |
|---|---|---|
| CMS | v0.2.0 | App v0.1.2 und Starterdaten 2026-09-23T13-54-03Z |
| App | v0.1.2 | CMS v0.2.0 und Starterdaten 2026-09-23T13-54-03Z |
| Starterdaten | 2026-09-23T13-54-03Z | CMS v0.2.0 und App v0.1.2 |
Der Compatibility-Datenstand verwendet den Schemafingerprint
c3653c0d7a5c2024773700862d0180f8bf5d565630748e7d006e168b7f8103cf.
Seine Archivdatei besitzt die SHA-256-Prüfsumme
4d52bffa2118e62aba82e21889ba33b2785db64559a3747f35cd855d88b7f10b.
Zusätzlich hält jedes GitLab Release unveränderlich fest, mit welchem Stand der jeweils anderen Komponente es geprüft wurde. Eine spätere Änderung der zentralen Empfehlung verändert diese historische Aussage nicht.
„Getestet mit“ ist enger und belastbarer als eine pauschale Kompatibilitätszusage. Versionsbereiche werden erst angegeben, wenn sie durch automatisierte Integrationstests abgedeckt sind.
Den passenden Datenstand auswählen
Öffentliche CMS-Datenstände haben zwei unterschiedliche Aufgaben:
latest.jsonverweist auf den aktuellen Rolling-Datenrelease. Er eignet sich für eine neue Installation des aktuell empfohlenen CMS-Codes.- Ein Compatibility-Datenstand gehört zu einer bestimmten CMS-Schema- Generation und wird dauerhaft mit den passenden CMS-Releases verknüpft.
Für die schnellste lokale Einrichtung kann der aktuelle Datenstand verwendet werden. Für eine reproduzierbare Installation eines älteren CMS-Tags sollte immer der im zugehörigen GitLab Release verlinkte Compatibility-Datenstand gewählt werden.
Ein Manifest nennt mindestens CMS-Tag und -Commit, Strapi-Version, Schemafingerprint, Archivgröße und SHA-256. Mehrere CMS-Tags dürfen denselben Compatibility-Datenstand verwenden, wenn ihr Schemafingerprint identisch ist und die Kombination erfolgreich importgetestet wurde.
Strapi-Importe überschreiben den bestehenden Zielbestand. Sie sollten nur in eine neue oder bewusst vorbereitete Instanz erfolgen; Medienziele verschiedener Umgebungen müssen voneinander getrennt sein.