Release- und Support-Politik¶

Kommunen planen Fachverfahren über Jahre. Diese Seite legt fest, wie mandari versioniert wird, wie oft Releases erscheinen, wie lange eine Version unterstützt wird, in welcher Frist Sicherheitslücken geschlossen werden und wie lange Schnittstellen stabil bleiben. Sie ist die verbindliche Grundlage für Betreiber, Selbstbetreiber und Vergabestellen.

Versionierung¶

mandari folgt Semantic Versioning 2.0 (MAJOR.MINOR.PATCH):

Vor 1.0 halten wir uns bereits an diese Regeln. MINOR-Versionen können bis 1.0 in Ausnahmefällen brechende Änderungen enthalten; sie stehen dann im Changelog unter „Brechend“ und bekommen eine Migrationsanleitung.

Die Container-Images tragen die Version als Tag, zum Beispiel v0.11.0. Dazu gibt es bewegliche und Entwicklungs-Tags, siehe Updates und Backups. Entwicklungsstände (dev, dev-<commit>) sind keine Releases und tragen keine Zusage. Zu jedem Release gehört eine Stückliste der Abhängigkeiten als Anhang (siehe Abhängigkeiten (SBOM)).

Release-Rhythmus¶

Zwei Monate sind kurz genug, damit Korrekturen nicht liegen bleiben, und lang genug, damit Kommunen mit Test- und Freigabeprozessen nachziehen können. Das von uns betriebene Hosting läuft zwischen den Releases auf erprobten Entwicklungsständen, die vor jedem Release in Produktion waren; ein Release ist damit nie der erste Kontakt mit echtem Betrieb.

Supportzeitraum je Version¶

Eine LTS-Linie gibt es ab 1.0 jeweils alle zwölf Monate. Bis dahin gilt: Wer selbst betreibt, bleibt auf einem unterstützten Stand, solange er die jüngste oder die vorherige MINOR-Version einsetzt und innerhalb von sechs Monaten nach einem MINOR-Release aktualisiert.

Betreutes Hosting: Wir aktualisieren alle gehosteten Instanzen spätestens 14 Tage nach einem Release, Sicherheitskorrekturen innerhalb der Fristen unten, ohne gesonderte Zustimmung. Angekündigt wird über die Statusseite status.mandari.de und, wenn sich die Bedienung ändert, per Mail an die hinterlegte Kontaktadresse.

Fristen für Sicherheitskorrekturen¶

Schweregrad nach CVSS 3.1:

Die Frist beginnt mit der Bestätigung der Meldung; den Eingang bestätigen wir innerhalb von drei Werktagen. Abhängigkeiten überwacht Dependabot, und die Prüfungen mit pip-audit und npm audit blockieren Änderungen mit bekannten Lücken ab „hoch“. Ist eine Korrektur in der Frist nicht möglich, veröffentlichen wir eine Übergangsmaßnahme (Konfiguration, Abschaltung einer Funktion) und einen Termin.

Sicherheitslücken melden Sie bitte nicht öffentlich, sondern an security@mandari.de; den Ablauf beschreibt SECURITY.md.

Schnittstellen und Abkündigung¶

Abkündigungen stehen im Changelog unter „Abgekündigt“ mit dem Datum des Wegfalls, in der Antwort der Schnittstelle als Header Deprecation (RFC 9745, Zeitpunkt der Abkündigung) und Sunset (RFC 8594, Zeitpunkt des Wegfalls) und in dieser Dokumentation. Ein Beispiel sind die alten Pfade der Session-API, die am 31.05.2027 entfallen (siehe Session-API v1). Felder werden nie umgedeutet; sie werden ergänzt oder nach Frist entfernt.

Changelog¶

Der Changelog folgt Keep a Changelog 1.1: je Release die Abschnitte Hinzugefügt, Geändert, Abgekündigt, Entfernt, Behoben und Sicherheit (mit GHSA- bzw. CVE-Kennung). Jedes Release ab 0.10.0 enthält einen Eintrag; ohne Eintrag wird kein Release gesetzt. Beim Veröffentlichen prüft die Release-Pipeline, dass das Tag zu den Versionsangaben im Code passt.

Sicherheitsmeldungen und Releases abonnieren¶

Auf einen Blick¶