Software Versionierungs-System | Kussin

Software Versionierungs-System


Mit Magento 2 wurde das Marketing vor die SemVer Versionnummer gesetzt und alle sind gefolgt.

11.12.2020 | Daniel Kussin | Entwicklung

Seit Magento 2 im November 2015 veröffentlicht wurde hat sich die Versionierungslogik von vielen Softwareprodukten stark verändert, denn Magento 2 ist nicht eine Weiterentwicklung von Magento 1, sondern ein komplett neues Produkt und die SemVer Versionnummer beginnt erst mit der zweiten Ziffer.

Semantic Versioning 2.0.0

Hinweis: SemVer schreibt in seinen Definitionen von APIs (Application Programming Interface), das bezeichnet einfach gesagt die jeweilige Software/Web-Applikation, wie z.B. Magento, OXID oder Shopware.

Die am häufigsten angewendete Versionierungslogik stammt von Tom Preston-Werner und wird im Projekt Semantic Versioning beschrieben:

Auf Grundlage einer Versionsnummer von MAJOR.MINOR.PATCH werden die einzelnen Elemente folgendermaßen erhöht:

  1. MAJOR wird erhöht, wenn API-inkompatible Änderungen veröffentlicht werden,
  2. MINOR wird erhöht, wenn neue Funktionalitäten, welche kompatibel zur bisherigen API sind, veröffentlicht werden, und
  3. PATCH wird erhöht, wenn die Änderungen ausschließlich API-kompatible Bugfixes umfassen.

Außerdem sind Bezeichner für Vorveröffentlichungen und Build-Metadaten als Erweiterungen zum MAJOR.MINOR.PATCH Format verfügbar.

Quelle: https://semver.org/lang/de/#zusammenfassung

Adobe Commerce (ehem. Magento 2)

Wie schon zuvor geschrieben, hat Adobe (ehem. eBay bzw. Varien) 2015 Magento 2 veröffentlicht, wobei Magento 2 nicht eine Weiterentwicklung von Magento 1 war, sondern eine komplette Neuentwicklung unter dem Namen Magento 2, somit veränderte sich die Versionierungslogik 2015 mit der Einführung der sogenannten Generation-Number, die fortan vor die Semantic Versioning gesetzt wurde.

Quelle: https://devdocs.magento.com/release/released-versions.html

OXID 7

UPDATE (11.08.2023): Release von OXID 7 (siehe https://www.oxid-esales.com/blog/release-oxid-7-der-sprung-aufs-neue-level/)

Im Grunde stimmt es nicht, dass Adobe mit Einführung von Magento 2 die Generation-Number erfunden hat, denn OXID hat bereits mit OXID 4 (Community & Professional Edition) bzw. OXID 5 (Enterprise Edition) die Generation-Number eingeführt, denn die Generation-Number hat damals den Funktionsumfang beschrieben.

2017 hat OXID dann entschieden, dass mit der Veröffentlichung von OXID 6.0.0 die beiden unterschiedlichen Versionen mit der selben Versionsnummer fortgeführt werden und nur noch die Kürzel CE, PE und EE den Funktionsumfang beschreiben, Hintergrund war, dass OXID 6 zwar im Kern auf OXID 5 basierte, aber viele Module inkl. Core komplett neuentwickelt wurden.
Am 22.04.2021 hat die OXID ESALES AG mitgeteilt, dass in Zukunft die Versionen CE & PE wegfallen werden und somit in Zukunft nur noch eine Versionsnummer ohne Kürzel mit Generation-Number weiterentwickelt wird (siehe https://www.oxid-esales.com/pressemitteilungen/).

Quelle: https://oxidforge.org/en/all-releases

Shopware 6

Mit der Veröffentlichung von Shopware 6 ist auch der letzte große Onlineshop-Provider in Deutschland mit auf die „Marketing-Aktion“ aufgesprungen und hat dazu direkt auch noch einen Blogbeitrag geschrieben, der uns inspiriert hat, diesen Beitrag zu erstellen:https://www.shopware.com/de/news/shopware-6-versionierungs-strategie/
Im Vergleich zu Magento, OXID & Co. gab es allerdings schon zuvor Shopware-Generation, allerdings führte Shopware 5 zum Durchbruch auf dem deutschen Onlineshop-Markt, so dass Shopware zu einem Synonym für Shopware 5 wurde und Shopware die 6 Generation als Produkt auf den Markt gebracht hat um sich vom veralteten „Shopware“ abzugrenzen.

Quelle: https://www.shopware.com/de/changelog/

WordPress/WooCommerce

Einzig WordPress hält sich noch an die Vorgaben von SemVer allerdings auch nur bedingt, denn i.d.R. bringen die Major-Updates von WordPress tiefgreifende Änderungen mit sich, weswegen wir – KUSSIN – die Versionierung intern auch angepasst haben.

Automatic Background Updates, mit WordPress 3.7 wurden automatische Hintergrund-Updates bei WordPress eingeführt, um die Sicherheit von WordPress zu erhöhen, denn viele Benutzer haben die Sicherheitsupdates selten oder gar nicht eingespielt, dieser Prozess wurde mit WordPress 5.5 noch einmal deutlich verbessert, führt aber zu Konflikten mit unserem Deployment Prozess.

Quelle: https://wordpress.org/news/category/releases/