Zum Inhalt

Versionierung

Schema

Seit v1.900.0 folgen Versionen dem Schema 1.<Linie>.<Patch>, z. B. 1.903.0, 1.903.1:

  • Neue Linie (zweite Stelle, 1.<Linie>.0) = Feature-Update: neue Funktionen, gebündelt.
  • Patch (dritte Stelle) = Sicherheitsupdate oder schnelle Fehlerbehebung auf einer bestehenden Linie. Ein Patch ändert nichts am Verhalten, bringt keine Datenbank-Migration und keine geänderte Compose-Datei mit.

Davor lief Vesana auf der Reihe 1.9.<n> (bis v1.9.453), in der jede Änderung ein eigenes Release war. Ein Sprung auf 2.0 ist eine bewusste Entscheidung mit Ankündigung, kein automatischer Nebeneffekt.

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

Tester-Linie und Freigabe für alle

Eine neue Linie geht zuerst nur an Instanzen mit Tester-Lizenz. Tester-Instanzen installieren sie wie jedes Update — automatisch, wenn das Auto-Update an ist. Bewährt sie sich, wird dieselbe Version für alle freigegeben — es wird nichts neu gebaut. Neuinstallationen (:latest) bekommen immer die aktuell freigegebene Version.

Eine normale Instanz sieht nur freigegebene Versionen und deren Patches. Liegen zwischen zwei Freigaben mehrere Tester-Linien, springt sie in einem Update darüber hinweg; die Release-Notes der Freigabe beschreiben den ganzen Sprung.

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.
  • Profile der Vesana-Bibliothek kommen nicht mit dem Vesana-Update, sondern aus der Bibliothek: lokal unveränderte aktualisieren sich automatisch, lokal geänderte übernimmt ein Super-Admin ü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; sie spielen nur vom Hersteller signierte Binaries ein und nie eine ältere Version. 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 Patch: Er erscheint auf der freigegebenen Linie (und, falls anders, auf der neuesten Tester-Linie) und erreicht damit sofort alle Instanzen dieser Linie. Mit dem Schalter „Sicherheitsupdates automatisch installieren" (bei Neuinstallationen an) wird er ohne Wartezeit eingespielt, auch wenn automatische Updates sonst aus sind; sonst per Klick unter Updates. Siehe Updates → Nur Sicherheitsupdates und Fehlerbehebungen automatisch.

Anschluss