Semantic versioning

Neu in Version 10.

Was?

Um Ihnen dauerhaft planbare Updates zu ermöglichen, wurde entschieden, dass die Versionen einem Schema folgen sollen.

Grundlage dafür ist das sogenannte Semantic versioning.

Was ist Semantic versioning

In der Welt der Softwareentwicklung existiert ein grauenhafter Ort namens “Dependency Hell”. Um so größer ein Projekt wird und je mehr Pakete in die Software integriert werden, desto wahrscheinlicher ist es, dass dieser fürchterliche Ort eines Tages betreten wird.

In Projekten mit vielen Abhängigkeiten kann das Aktualisieren abhängiger Pakete schnell zum Albtraum werden. Sind die Abhängigkeitsspezifikationen des Pakets zu strikt, besteht die Gefahr des “Version Lock” (die Unfähigkeit ein Paket zu aktualisieren, ohne, dass alle abhängigen Pakete dieses Pakets ebenfalls aktualisiert werden müssen). Wenn die Abhängigkeiten des Pakets allerdings zu lasch definiert sind, wird sehr wahrscheinlich ein Problem, das sich “Version Promiscuity” nennt (das Paket gibt vor, mit mehr zukünftigen Versionen seiner abhängigen Pakete kompatibel zu sein, als angemessen ist), eintreten. Dependency Hell bezeichnet die Situation, in der entweder Version Lock oder Version Promiscuity, oder beides den Entwicklungsprozess des Projekts beeinträchtigt.

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

Anpassungen für die Musterwebseiten

abweichend / erweiternd zu den Regeln für Semver

  • MAJOR wird erhöht, wenn API-inkompatible Änderungen veröffentlicht werden,

  • MINOR wird erhöht, wenn neue Funktionalitäten, welche kompatibel zur bisherigen API sind, veröffentlicht werden, und

  • PATCH wird erhöht, wenn die Änderungen ausschließlich API-kompatible Bugfixes umfassen.

Wir orientieren uns an Semver mit kleinen Änderungen an der 1. und 3. Stelle: Damit kommen wir bei dem folgenden Schema raus

  • MAJOR: TYPO3 Basis Version - was uns im Grunde zwingt Breaking Changes nur mit neuen TYPO3 Releases zu machen

  • MINOR: Neue Funktionen, die aber API kompatibel sind

  • PATCH: Reine Bugfixes, die aber API kompatibel sind

Damit würden wir den üblichen Standards folgen. Branches gibt es damit für jede neue Major Version

  • 10.x

  • 9.x

Tags sehen dann wie folgt aus:

  • 10.0.1

  • 9.5.6

Sprich, immer wenn wir die TYPO3 Hauptversion im master ändern, wird für den alten Zweig ein Branch angelegt. Damit ist auch immer klar kommentiert, welche Version im Einsatz ist.

TYPO3 Roadmap

Informationen zur TYPO3 Roadmap finden sich auf der offiziellen Projektwebseite: