Versionierung / Tagging

Hier werden veraltete News archiviert
Antworten
Benutzeravatar
shadowcat
Administrator
Beiträge: 4097
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Versionierung / Tagging

Beitrag von shadowcat » Mo 25. Mär 2013, 10:18

Da schon die ersten Interessenten die Entwicklung begleiten, haben wir jetzt eine numerische Versionierung eingeführt. Die Versionierung beginnt jetzt mit 0.1.0, die Release-Version wird dann die Version 1.0.0 haben. Wir verwenden hierfür das Tagging, was im Umfeld von Versionsverwaltungssoftware das Festhalten eines bestimmten Standes bedeutet. In der aktuellen Entwicklungsversion 0.x werde ich in der Regel dann ein Tag erzeugen, wenn ich mindestens die Installation getestet habe. Das heißt dann aber nicht, daß auch der Rest funktioniert. Dafür sind es halt Entwicklungs-Snapshots. ;) Vor der offiziellen Beta sind die sozusagen schon per Definition (mehr oder weniger) "kaputt".

Die Versionsnummer hat folgende Bedeutung:

Die erste Stelle
...bezeichnet das "Major Release", also die Hauptversion. Wir beginnen mit 0, nicht mit 1, weil wir ja noch auf die Version 1.0 hinarbeiten.

Die zweite Stelle
...bezeichnet das "Minor Release", also eine Unterversion. Unterversionen beinhalten eine Summe von Bugfixes und neuen Funktionen, die wir zu irgendeinem Zeitpunkt als neue Version freigeben.

Die dritte Stelle
...verwenden wir für Patches. Patchversionen werden in der Regel dann herausgegeben, wenn eine Korrektur dringlich ist und wir deshalb nicht auf das nächste Minor Release warten wollen.

So lange die Versionsnummer mit 0 beginnt, werden wir obige Struktur nicht so streng einhalten, da diese Version ohnehin nicht für den produktiven Einsatz gedacht ist. Ab Version 1.0(.0) kann man sich dann aber darauf verlassen.

GitHub erzeugt mit dem Hinzufügen eines Tags automatisch einen Download, also ein Zip. Die vorhandenen Tags = Zips = Stände können hier eingesehen werden:

https://github.com/webbird/LEPTON_2_BlackCat/tags
My software never has bugs, it just develops random features.
BC1: PHP 5.5.11 (cli), mySQL 5.6.16 with 'strict' enabled, Apache 2.4.9
BC2: PHP 7.2.7, mariaDB 10.2.13, no Apache

Benutzeravatar
shadowcat
Administrator
Beiträge: 4097
Registriert: Di 5. Feb 2013, 10:36
Kontaktdaten:

Versionszusätze

Beitrag von shadowcat » Di 14. Mai 2013, 09:08

Ein Versionszusatz bezeichnet eine zusätzliche Angabe zur Versionsnummer, also z. B. v1.0.0Beta. Grundsätzlich gilt: Versionen mit Versionszusatz sind nicht für den produktiven Einsatz geeignet.

Im Gegensatz zu Website Baker verwenden wir keine "Service Packs" (SPx), da wir hierfür die dritte Stelle der Versionsnummer vorgesehen haben. Es gibt also keine Version v1.0.1SP1 oder ähnliches.

Folgende Versionszusätze werden von uns verwendet:

Alpha

"Die erste zum Test durch Fremde (also nicht die eigentlichen Entwickler) bestimmte Version." --> https://de.wikipedia.org/wiki/Entwicklu ... ha-Version

Alpha-Versionen werden von uns in der Regel dann herausgegeben, wenn alle Funktionalitäten, die für eine Version planmäßig vorgesehen sind, eingearbeitet sind. Da es sich um frühe "Vorschau-Versionen" handelt, ist mit einer größeren Anzahl an Fehlern zu rechnen; auch schwerwiegende Fehler können noch enthalten sein.

Alpha-Versionen richten sich an ambitionierte Tester, die sich schon in einem frühen Stadium beteiligen wollen.

Es ist möglich, daß sich im Zeitraum der Alpha- und folgenden Beta-Tests noch Anforderungen ergeben, die zu einer Erweiterung des ursprünglich geplanten Funktionsumfangs führen.

Beta

Beta-Versionen sind im Prinzip fehlerbereinigte Alpha-Versionen mit deutlich höherer Stabilität, die aber immer noch viele und auch schwerwiegende Fehler beinhalten können.

Der Kreis der Beta-Tester ist üblicherweise größer als der der Alpha-Tester, da die Version schon deutlich stabiler ist und mehr Möglichkeiten bietet, etwa wenn ganze Funktionsbereiche in der Alpha noch fehlerbehaftet waren und daher gar nicht erst funktionierten.

Es ist möglich, daß sich im Zeitraum der Beta-Tests noch Anforderungen ergeben, die zu einer Erweiterung des ursprünglich geplanten Funktionsumfangs führen. Größere Erweiterungen werden jetzt aber nur noch vorgenommen, wenn es sich um schwerwiegende Probleme, etwa Sicherheitslücken, handelt. Alle anderen werden auf das nächste Major Release verschoben.

RC / Release Candidate

Hierbei handelt es sich um die letzte Testversion vor dem endgültigen Release. Hier sind jetzt alle Funktionen enthalten, die auch die abschließende Version beinhalten wird. ("Feature complete") Alle bis dahin bekannten Fehler sind behoben. Aus dem Release Candidate wird vor der Veröffentlichung die endgültige Version erstellt, um einen abschließenden Produkttest durchzuführen. (https://de.wikipedia.org/wiki/Entwicklu ... Prerelease)

Release

Dies ist kein Versionszusatz, sondern bezeichnet die fertige und veröffentlichte Version. Anders ausgedrückt, das Fehlen der obigen Versionszusätze bezeichnet eine freigegebene Version.

Nur Release-Versionen sind für den produktiven Einsatz gedacht, alle anderen Versionen dienen ausschließlich Testzwecken. Wer trotzdem eine Alpha, Beta oder RC produktiv einsetzt, tut dies auf eigene Gefahr.
My software never has bugs, it just develops random features.
BC1: PHP 5.5.11 (cli), mySQL 5.6.16 with 'strict' enabled, Apache 2.4.9
BC2: PHP 7.2.7, mariaDB 10.2.13, no Apache

Antworten