Versionierung¶

Schema¶

Vesana läuft auf der 1.9-Linie: 1.9.<Patch>. Jede Änderung, die Self-Hoster bekommen sollen, ist ein eigenes Release — deshalb steigt die Patch-Zahl schnell (mehrere Releases pro Tag sind normal). Ein Release kann ein einzelner Fix oder ein Sammel-Release aus mehreren Änderungen sein; die Release-Notes in der Instanz (Admin → System → Updates) listen jede davon. Ein Sprung auf 2.0 ist eine bewusste Entscheidung mit Ankündigung, kein automatischer Nebeneffekt.

Versionen tragen in Tags ein v (v1.9.436); in der Oberfläche und in API-Antworten steht der nackte Wert.

Was ein Update mitbringt¶

Container-Images für alle Dienste; der Updater tauscht sie in einem Zug und legt vorher automatisch ein Backup an.
Datenbank-Migrationen, die der Init-Container beim Start ausführt — immer additiv: neue Tabellen, neue Spalten mit Standardwert, neue Indizes, neue mitgelieferte Daten. Nichts wird umbenannt oder gelöscht; überflüssig gewordene Spalten bleiben stehen.
Agents und Collectors aktualisieren sich danach von selbst (Minuten), ebenso der Aktive Collector.
Community-Profile werden nicht automatisch angefasst — Profil-Updates übernimmst du bewusst über die Vorschau.

Mehrere Versionen auf einmal überspringen ist unterstützt; Migrationen laufen der Reihe nach.

Rollback¶

Einen Downgrade gibt es nicht: ältere Images kennen die neueren Tabellen nicht, und die Datenbank wird nie zurückmigriert. Der Rückweg ist das Backup: Der Updater legt vor jedem Update automatisch eines an; ein Restore legt die Datenbank frisch aus dem Backup an (Backup & Restore). Alles seit dem Backup geht dabei verloren — deshalb: Backup prüfen, dann updaten.

Wer Releases erst reifen lassen will, nutzt bei den automatischen Updates die Wartezeit nach Release — installiert wird dann immer die neueste Version, die die Wartezeit überstanden hat; ein sofort ersetztes Release geht an der Instanz vorbei.

Breaking Changes — Politik¶

Ein Change gilt als breaking, wenn bestehende API-Clients mit identischem Code Fehler bekommen, bestehende Agents/Collectors nicht mehr funktionieren oder bestehende Konfigurationen ohne Migration ungültig werden. Solche Änderungen stehen in den Release-Notes ausdrücklich mit ⚠️ und dem nötigen Handgriff (z. B. „Viewer können nicht mehr quittieren — Rolle anpassen"). Nicht breaking: neue optionale Felder, neue Endpunkte, mehr Detail in Fehlerantworten, neue Oberflächenpfade, neue Berechtigungen (die eingebauten Rollen bekommen sie beim Start automatisch nachgereicht).

Entfernte Funktionen (E-Mail-2FA, native App, Log-Regeln) werden im Release angekündigt; die zugehörigen Datenbank-Spalten bleiben additiv stehen.

API-Versionierung¶

/api/v1/ ist stabil. Neue Felder kommen hinzu, bestehende ändern ihre Bedeutung nicht. Das Live-Schema der laufenden Instanz ist die maßgebliche Referenz (API-Referenz).

Agent- und Collector-Versionen¶

Agent und Collector haben eigene Versionsnummern und aktualisieren sich vom Server (Signaturprüfung). Ein Server-Update kann eine neue Agent-Version mitbringen; Funktionen, die einen neuen Agent brauchen (z. B. Hardware-Telemetrie, Docker-Tab), erscheinen, sobald der Agent nachgezogen hat. Alte Agents bleiben funktionsfähig, bis sie aktualisiert sind.

Hotfixes¶

Ein Hotfix ist ein normales Patch-Release — es gibt keinen separaten Kanal. Wer die Wartezeit der automatischen Updates auf „Sofort" stellt, bekommt ihn binnen Minuten; sonst nach Ablauf der Wartezeit oder per Klick unter Updates.