Dürfen wir vorstellen: Das neue Versionsschema von Sophora

20.02.2020

In Systemen mit vielen Komponenten kann das Aktualisieren einzelner Komponenten schnell kompliziert werden. Ist eine neue Version einer Komponente verfügbar, möchte man möglichst einfach das Risiko einer Aktualisierung erkennen. Aussagekräftige Versionsnummern können dabei helfen. Deshalb haben wir mit dem Start von Sophora 3 ein neues Versionsschema eingeführt. Hier könnt Ihr lesen, was wir uns dabei gedacht haben. 

Worum geht es konkret? Die Versionsnummern der verschiedenen Komponenten von Sophora, wie Server, DeskClient oder Importer, geben Hinweise auf die Kompatibilität der Komponenten untereinander und zu älteren Versionen. Mit dem Wechsel von Sophora 2.5 zu Sophora 3 ändert sich das Schema der Versionsnummern. Mit dem neuen Schema können unsere Kunden leichter erkennen, was bei einem Upgrade zu erwarten ist.

Das alte Schema bis Sophora 2.5

Bisher hatten ausschließlich die zweite und dritte Stelle der Versionsnummer eine wirkliche Bedeutung. Entsprechend wurde die erste Stelle der Versionsnummer nur ein einziges Mal in der Geschichte von Sophora geändert, und zwar von 1.53.x auf 2.0.x.

Ein Wechsel der zweiten Stelle, z.B. von Sophora 2.4 auf 2.5, wurde ein Major-Release genannt. Bei so einem Wechsel mussten alle Komponenten von Sophora, wie Server, DeskClient oder Webausspielung zur gleichen Zeit aktualisiert werden.

Der Grundsatz war, dass bei einer Sophora-Installation von allen Komponenten die erste und zweite Stelle der Version gleich sein mussten. So war ein Server 2.5.20 kompatibel mit einem DeskClient 2.5.44 und einem Importer 2.5.1, aber z.B. nicht mit einem DeskClient 2.4.4.

Bei Änderung der dritten Stelle enthielt die neue Version abwärtskompatible Bugfixes oder auch Features.

Das neue Schema ab Sophora 3

Das neue Versionsschema folgt grundsätzlich dem Prinzip des „Semantic Versioning“. Das besteht darin, dass es drei Felder gibt, um die Veränderungen im System zu benennen: MAJOR, MINOR und PATCH.

Mit jeder neuen Version einer Sophora-Komponente werden die einzelnen Felder nach dem folgenden Prinzip erhöht:

1. MAJOR wird erhöht, wenn sich die Sophora-API ändert und alle Sophora-Komponenten auf einmal aktualisiert werden müssen – also nur bei großen Releases.
2. MINOR wird erhöht, wenn es ein neues Feature oder Änderungen in der Bedienung gibt oder wenn beim Upgrade besondere Schritte zu beachten sind.
3. PATCH wird erhöht, wenn die Änderungen nur Bugfixes und kleinere Verbesserungen enthalten und beim Upgrade nichts Besonderes zu beachten ist.

Nach Sophora 3 wird das nächste MAJOR-Release also folgerichtig Sophora 4 sein. Wenn es ein MINOR-Release gibt, also z.B. ein neues Feature, kann dies ohne weiteres integriert werden. Anders als früher können Komponenten mit unterschiedlichen MINOR-Versionen miteinander betrieben werden, denn innerhalb eines MAJOR-Releases sind alle Komponenten zueinander kompatibel. Man kann z.B. einen DeskClient 3.0.8 zusammen mit einem Server 3.2.0 betreiben.

Auch bei Bugfixes kann es vorkommen, dass beim Upgrade etwas zu beachten ist und evtl. manuelle Schritte notwendig sind. Daher kann MINOR auch erhöht werden, wenn das neue Release nur Bugfixes enthält. Um zu wissen, ob bei der Installation eines MINOR-Releases etwas zu beachten ist, empfiehlt sich ein Studium der Release Notes zur jeweiligen Version von Sophora.

Nicht nur unsere Versionsnummern, auch wir vom Team subshell geben gerne Auskunft – und sind für alle Releases bestens vorbereitet.

Jens Theeß