Was ist semantische Versionierung und funktioniert sie auch für Systeme?

In den 2000er Jahren träumten Entwickler von Softwarekomponenten, die Entwickler wie Legosteine verbauen würden. Das ist inzwischen Realität. Möglich ist dies durch ein reiches Ökosystem von extrem nutzerfreundlichen, in der Regel kostenlosen Werkzeugen.

Doch dieses Öksystem funktioniert unter anderem deshalb, weil die Softwarekomponenten semantisch versioniert werden. Was genau semantische Versionierung ist, und warum wir diese immer noch nicht im Systems Engineering haben, darum geht es in diesem Artikel.

Semantische Versionierung

Semantische Versionierung (SemVer) löst das Problem, Abhängigkeiten von Softwarekomponenten zu lösen. Daher bezieht es sich auf „Einheiten“, deren Abhängigkeiten verwaltet werden müssen. Das kann die Software selbst sein, es können aber auch Bestandteile der Software sein (also Softwarekomponenten). Aber auch Schnittstellen (APIs) und Spezifikationen benötigen in der Regel eine Versionierung.

Semantic Versioning 2.0.0 & FAQ

Offizielle Spezifikation

Semantische Versionierung basiert auf drei Zahlen, die durch Punkte getrennt sind: MAJOR.MINOR.PATCH (z. B. 16.1.25). Jede dieser Zahlen hat eine spezifische Bedeutung:

1. MAJOR: Änderungen, die inkompatibel mit früheren Versionen sind.
2. MINOR: Hinzufügungen von Funktionalitäten, die abwärtskompatibel sind.
3. PATCH: Fehlerbehebungen und andere kleinere Änderungen, die keine neuen Features hinzufügen und kompatibel bleiben.

Vorteile der semantischen Versionierung

Das Ziel der semantischen Versionierung ist es, eine klare und verständliche Kommunikation über die Änderungen an einer Software zu gewährleisten. Entwickler können anhand der Versionsnummer sofort erkennen, ob ein Update Risiken birgt oder einfach installiert werden kann. Semantische Versionierung ist sehr verständlich und macht auch intuitiv Sinn. Daher ist es ein hervorragendes Kommunikationswerkzeug.

Semantische Versionierung macht intuitiv Sinn und verbessert die Kommunikation.

Für die Entwickler ist klar, dass ein Sprung in der Major-Version eine Nacharbeit erfordert und daher nur mit gutem Grund durchgeführt werden sollte. Im Gegensatz dazu sollten Patches zügig eingearbeitet werden. Denn durch Patches sollten sich keine Funktionalitäten ändern. Patch-Releases bestehen zum größten Teil aus Bugfixes und dem Schließen von Sicherheitslücken.

Minor-Versionen bringen das Beste von beiden Welten. In der Regel können diese ohne Bedenken angewandt werden, da sie Abwärtskompatibel sind. Gleichzeitig bringen sie neue Features. Zum Beispiel könnte eine Bibliothek für die Bildverarbeitung ein neues Bildformat unterstützen. Die bestehenden Funktionen werden dadurch nicht verändert.

Semantische Versionierung maschinell verarbeiten

Doch wirklich mächtig wird SemVer durch das automatische Verwalten von Abhängigkeiten. Inzwischen hat jedes ernsthafte Programmier-Ökosystem ein Komponentensystem, das semantische Versionierung nutzt. Ich hatte bereits Anfang der 2000er Erfahrung mit OSGi gesammelt, dem Komponentenmodell, das von Eclipse genutzt wird.

In einem typischen Entwicklungsprojekt halten wir die Abhängigkeiten unserer Software in einer Konfigurationsdatei fest. Wer mit Node.js arbeitet, würde das in der Datei package.json machen. Hier ein kleines Beispiel, dass die wesentlichen Aspekte der semantischen Versionierung zeigt. Der Präfix vor der Nummer legt deren Bedeutung fest:

{
  "dependencies": {
    "typisch-package": "^1.4.0"
    "fix-minor-package": "~1.4.0"
    "flexible-package": ">=1.0.0 <3.0.0"
  }
}

• typisch-package (^): Alles in dieser Major-Version ab 1.4.0 ist erlaubt, also 1.4.0, 1.4.2, 1.5.3. Verboten ist alles vor 1.4.0 und alles ab 2.0.0. Dies ist der in der Praxis häufigste Fall.
• fix-minor-package (~): Wir können auch strenger sein und andere Major-Versionen verbieten. In diesem Beispiel ist 1.5.0 und besser verboten.
• flexible-package (>, = <): Mit den üblichen mathematischen Operatoren können wir quasi jeden gewünschten Versionsbereich einstellen.

Jedes der aufgeführten Pakete hat natürlich selbst wiederum Abhängigkeiten, so dass sich ein großer Baum von

In einer modernen Anwendungen sind häufig hunderte von Paketen verbaut, was zu Problemen mit den Abhängigkeiten führen kann. Wenn zum Beispiel zwei Komponenten dieselbe Komponente zum Loggen verwenden, dann muss eine Version gefunden werden, die für beide Projekte passt.

Wenn also die eine ^1.4.0 verlangt und die andere ~1.5.2, dann muss eine Version ausgewählt werden, die beide Bedingungen erfüllt. Um hier eine passende Konfiguration zu finden, müssen alle Constraints berücksichtigt werden. Ein Constraint Solver findet dann eine passende Konfiguration.

Der Erfolg von Paketmanagement ist übrigens auch der Grund, warum das log4j-Desaster so viele Programme betroffen hatte: Die meisten Programme hatten die Komponente lediglich indirekt über Abhängigkeiten integriert, wie sich in dem folgenden Bild schön erkennen lässt:

Umgekehrt ließ sich über diesen Weg die Sicherheitslücke auch nachhaltig schließen: Sobald ein Entwickler die betroffene Version über die semantische Versionierung verboten hatten, hat der Constraint Solver sichergestellt, dass kein verbautes Paket dieses Paket benutzt.

Semantische Versionierung im Systems Engineering

Im Gegensatz zur Softwareentwicklung ist das Systems Engineering ein Bereich, der oft physische und digitale Komponenten kombiniert. Trotz des zunehmenden Softwareanteils in solchen Systemen bleibt die Idee einer einheitlichen semantischen Versionierung schwierig umzusetzen. Warum?

Komplexität der Abhängigkeiten — Ein Softwareprojekt kann relativ einfach Abhängigkeiten zu anderen Paketen definieren. Ein System hingegen besteht oft aus einer Vielzahl von Bausteinen: Mechanik, Elektronik, Software und anderen Komponenten, die miteinander interagieren. Eine kleine Änderung an einem Teil des Systems könnte unerwartete Auswirkungen auf andere Teile haben.

Fehlende Standards — Während SemVer in der Softwarewelt gut etabliert ist, gibt es im Systems Engineering keine vergleichbare, weit verbreitete Praxis. In der Softwareentwicklung gibt es ein reichhaltiges, oft kostenloses Angebot an Werkzeugen Frameworks, Bibliotheken und vielem mehr. Im Systemsengineering sind wir meilenweit davon entfernt.

Lange Entwicklungszyklen —In der Softwareentwicklung sind kurze Release-Zyklen üblich. Neue Features oder Bugfixes werden oft innerhalb von Wochen oder sogar Tagen veröffentlicht. Im Systems Engineering können Entwicklungszyklen hingegen Jahre dauern. Eine standardisierte Versionierung könnte hier weniger effektiv erscheinen, da Änderungen seltener auftreten. Was ich allerdings als Fehlschluss ansehe, und manche Unternehmen arbeiten mit 2tägigen Release-Zyklen für komplexe Produkte wie Raketentriebwerke.

Unterschiedliche Lebenszyklen — Ein Softwarepaket kann regelmäßig aktualisiert werden, oft ohne physische Einschränkungen. Physische Systeme hingegen haben Lebenszyklen, die von Wartung, Verfügbarkeit von Ersatzteilen und regulatorischen Vorgaben abhängen. Eine Versionierung müsste diese Faktoren berücksichtigen. Daher erkläre ich schon lange, dass diese Zyklen lose gekoppelt werden müssen (was mit SemVer auch gut funktioniert)

Ein Weg nach vorne: Automatisierung und Schnittstellenversionierung

Wir werden semantische Versionierung sicher nicht auf einen Schlag im Systems Engineering realisieren können. Ich sehe insbesondere zwei Punkte, an denen wir ansetzen können.

Zum einen müssen wir zwangsläufig mehr automatisieren. Eine effektive Automatisierung erfordert eine vernünftige Versionierung (zumindest dann, wenn wir Aufgaben nicht doppelt und dreifach ausführen wollen, selbst automatisiert). Semantische Versionierung unterstützt Automatisierung, da über diesen Weg automatisiert veraltete Artefakte identifiziert werden können. Das Änderungsmanagement wird automatisiert.

Weiterhin empfehle ich, bei den Schnittstellen zu beginnen. Wenn wir versuchen, die Schnittstellen semantisch sauber festzuhalten, wird dieser Prozess auch die Qualität der Schnittstellen schärfen und Probleme bei der Integration reduzieren. Dazu ein Beispiel:

USB: Versionierung von Hardware- Elektronik- und Softwareschnittstelle

Der USB-Standard ist ein gutes Beispiel für eine komplexe Versionierung, die mehrere Ebenen abdeckt. Auf der mechanischen Ebene werden verschiedene Steckertypen wie USB-A, USB-B, Micro-USB, USB-C oder Mini-USB spezifiziert. Änderungen an der mechanischen Spezifikation werden häufig mit neuen Hauptversionen des Standards eingeführt, etwa der Wechsel zu USB-C, der nicht nur eine neue Steckerausführung brachte, sondern auch die Grundlage für viele weitere Verbesserungen schuf.

Auf der elektrischen Ebene geht es um Spannungen, Signale und Ladeströme, wie sie etwa mit USB Power Delivery (USB PD).

Auf der softwareseitigen Ebene geht es um Protokolle wie USB 2.0, 3.0, 3.1 oder 4.0. Diese Protokolle bestimmen die Geschwindigkeit und Funktionalität der Datenübertragung und setzen auf den jeweiligen mechanischen und elektrischen Standards auf. So ermöglicht etwa USB 3.0 eine signifikant höhere Übertragungsgeschwindigkeit als USB 2.0, bleibt dabei aber teilweise abwärtskompatibel. Diese vielschichtige Versionierung sorgt für eine klare Trennung der Verantwortlichkeiten und eine schrittweise Einführung neuer Technologien, ohne bestehende Systeme sofort obsolet zu machen.

Fazit: SemVer als Inspiration für Systeme

Semantische Versionierung hat die Softwareentwicklung revolutioniert und ein ganzes Ökosystem moderner Werkzeuge ermöglicht. Für das Systems Engineering könnte sie ähnliche Vorteile bringen.

Auch wenn das Systems Engineering noch lange nicht soweit ist wie die Softwareentwicklung, können wir dennoch an vielen Stellen semantische Versionierung nutzen, wo in der Vergangenheit einfache Versionsbezeichner benutzt wurden. Die Versionierung von Schnittstellen steht da an erster Stelle.

Die Frage ist also nicht, ob semantische Versionierung für Systeme funktioniert, sondern wie sie am besten umgesetzt werden kann.

Image by Bruno from Pixabay