Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
81 lines (49 sloc) 4.58 KB

##WBCE Semantische Versionierung (Version 1.0.0-rc.1)

Wir benutzen Semantische Versionierung nach http://semver.org und zwar für den Core verbindlich sowie für Module als Empfehlung. Im weiteren abgekürzt als SemVer.

###Spezifikationen und Optionen innerhalb von SemVer

  • Wir nutzen Option 9 (Kennzeichnung vor Vorveröffentlichungen)

  • Valide Vorversionen sind : "alpha", "beta" und "rc" Diese Reihenfolge ist verbindlich, allerdings können einzelne Schritte oder die gesamten Vorversionen übersprungen werden. Zum Beispiel kann eine Veröffentlichung mit nur einer einzigen Änderung direkt als stabil herausgegeben werden.

  • Vorversionen starten immer mit Version .1
    z.B. 1.0.0-alpha.1 , 1.0.0-beta.1

###Erklärungen

Die Aktuelle Versionsnummer einer Veröffentlichung wird bei der ersten alpha Veröffentlichung nach den Kriterien von SemVer festgelegt. Also Bugfix, Minor oder Major.
Danach werden bis zur Veröffentlichung nur noch die Vorversionen hochgezählt. Das ganze geht üblicherweise mit einem "Feature Freeze" also einen Stopp für neue Funktionalitäten einher.

Sollten während der Vorveröffentlichungsphase unerwarteterweise weitergehende Änderungen nötig werden, die gegen die Versionierungsregeln von Semver.org verstoßen, so wird die Version auf die nächstnotwendige angehoben.
Beispiel: Wir sind in Version 1.1.3-beta.4, aber um einen Bug wirklich zu beheben, müssen neue Funktionalitäten eingebaut werden. Dann würde die Version auf 1.2.0 angehoben. Wobei der neue Status der Vorversion dann davon abhängt, was die Änderung bewirkt hat. So könnte der Status stabiler oder instabiler geworden sein oder sich nicht geändert haben. In jedem Fall aber fangen wir wieder mit .1 an. (1.2.0-alpha.1, 1.2.0-beta.1, 1.2.0-rc.1)
Dieser Schritt sollte aber nur in Ausnahmesituationen genutzt werden und auch nur dann, wenn merkliche Änderungen für den Nutzer entstehen.

Die Konstanten WBCE_VERSION und WBCE_TAG(/admin/interface/version.php) sowie der Versionstag auf Github werden alle einheitlich auf die gleiche durch dieses Dokument definierte Zeichenfolge gesetzt.

###Anmerkungen

Es bleibt stets zu bedenken, dass viele der Definitionen einen gewissen Auslegungsspielraum haben - wenn eine Versionsangabe nicht auf den ersten Blick logisch erscheint, einfach nachfragen.

Als API können wir im Moment leider nur die Codebase definieren, da eine echte API-Dokumentation noch nicht wirklich vorhanden ist. Alle neuen Klassen und Features werden allerdings umfassend dokumentiert, wodurch sich das Problem Schritt für Schritt auflösen dürfte.

###Empfehlungen Die PHP Funktion version_compare() unterstützt diese Versionsschema, deswegen empfehlen wir für Versionsvergleiche diese Funktion zu nutzen.

###Beispiel

Aktuelle Version:
1.4.2

Die Testversion (im Master Repository) ist soweit gediehen, das ein Alphatest stattfinden kann.

Dann sollte jetzt ein "Feature Freeze" erklärt werden, also einen Stopp für neue Funktionalitäten.

In dieser Version sind wie immer einige Bugs gefixt und vor allem einige neue Features hinzugekommen. Neue Features bedeutet eine neue Minor-Veröffentlichung.

Also heißt die neue Veröffentlichung:
1.5.0-alpha.1

Diese durchläuft nun mehrere Testphasen:
1.5.0-alpha.2, 1.5.0-alpha.3, 1.5.0-beta.1, 1.5.0-rc.1, 1.5.0-rc.2

Und wird dann letztendlich zur Stabilen Version:
1.5.0

Wenn jetzt zum Beispiel in der 1.5.0-beta.3 festgestellt würde, dass eine bestimmte Funktionalität entfernt werden muss (z.B. weil sie den neuen Features im Weg steht), so haben wir die Möglichkeit (und möglicherweise die Pflicht), die Version auf 2.0.0 anzuheben. Hier im Beispiel gehen wir davon aus das wir uns immer noch im beta Stadium befinden.
Also:
2.0.0-beta.1

Dabei sollte immer im Hintergrund die Änderung aus Sicht der Nutzer stehen. Sprich, erzeuge ich eine so große Änderung in dem Erleben des Benutzers, das solch eine Maßnahme gerechtfertigt ist?

Bei klaren Inkompatibilitäten mit vorherigen Versionen ist die Erhöhung der Version auf jeden Fall erforderlich, damit der Nutzer gewarnt ist, wenn er diese Version installiert. Ansonsten muss das individuell entschieden werden.

Nach dieser Erhöhung wird normal weiter gezählt:
2.0.0-beta.2, 2.0.0-rc.1, 2.0.0-rc.2 und dann 2.0.0


###License

Dieses Dokument ist Lizensiert unter der Creative Commons Lizenz:
Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Deutschland (CC BY-SA 3.0 DE)
https://creativecommons.org/licenses/by-sa/3.0/de/

Autoren: Norbert Heimsath (heimsath.org)
Christian Sommer (cwsoft)

--

You can’t perform that action at this time.