Versions-/Versionierungskonzept?

[Flori]

Hallo zusammen,

mir ist neulich mal die Frage in den Sinn gekommen, ob es für die Art und Weise der Versionsnummern-Vergabe von Software-Produkten eigentlich bereits fertige Konzepte oder Vorgaben à la DIN oder anderer Institutionen gibt.

Wenn ja, würde mich interessieren, ob jemand Quellen kennt wo man diese Empfehlungen / Vorgaben einsehen kann. Oder definiert das jeder für sein Produkt selbst? Tue mich jedenfalls noch schwer, ob ich nach Änderungen meiner Anwendung, das Produkt "Anwendung Version 0.9" oder "Anwendung Version 0.9.1" oder "Anwendung 0.9.1.1" nennen darf, kann oder soll....

Wann ist ein Produkt soweit, daß es die "Version 1.0" führen darf / sollte? Wann ist es soweit das man eine volle Nummer raufgeht? Wieviele Unterebenen sollte es geben bei der Versionierung?

Wie ihr seht, viele Fragen auf einmal...hoffe, ihr versteht so, was ich meine und jemand hat da ein paar Tipps (evtl. auch aus eigener Erfahrung!) für mich.

Vielen Dank für Eure Hilfe im Voraus!!!

Grüße

Flori

[perdian]

Also DIN-Normen oder ähnliches ist mir für Versionierung nicht bekannt - da hat wohl auch jeder seine Art und Weise zu zählen. Was für den einen noch Version 0.128.12 ist, hat manch anderer schon als 2.1 auf den Markt gebracht, immer auch eine Sache des Blickwinkels.

Ein Programmierer wird eine Version anders definieren, als ein Marketing-Leiter. Schönes Beispiel ist Windows 2000 - die Marketing-Version ist halt 2000, die interne Version 5.00.2195.

Was ich ganz interessant und klar strukturiert finde ist die Versionierung von Eclipse:

http://dev.eclipse.org/viewcvs/index.cgi/platform-core-home/documents/plugin-versioning.html?rev=1.5

Wann ist ein Produkt soweit, daß es die "Version 1.0" führen darf / sollte?

Vom Gefühl her würde ich sagen, "Version 1.0" ist die erste Version mit allen für den Produktstart angedachten Funktionalitäten. Das heisst, meine Entwicklung fängt bei 0.1 an, und wenn alle Features implementiert sind gibt es einen Versionsprung nach 1.0

Da natürlich auch während der Entwicklung immer neue Features gefordert werden, oder man merkt "Oh ja, das könnte man auch noch umsetzen" erweitert sich sowas mehr oder weniger ständig.

Deshalb kenne ich Software, die im 0.3 Release schon einwandfrei funktioniert und genau das tut, was man von ihr verlangt, wogegen es andere Software gibt, die beim Release 2.0 noch immer Bugs der ersten Stunde mit sich rumschleift.

Wieviele Unterebenen sollte es geben bei der Versionierung?

Ich denke drei Ebenen reichen vollkommen aus, alles was darüber hinausgeht wird sehr schnell unübersichtlich. Wenn man denn wirklich eine Mini-Änderung durchgeführt hat dann würde ich eher hingehen und von 1.1.2b auf 1.1.2c switchen um zu signalisieren "Es hat sich zwar was getan, aber das wir kaum jemand merken".

[Flori]

Vielen Dank, perdi, für Deine ausführliche Antwort!

Ähnliche Überlegungen hatte ich zu dem Thema auch schon angestellt. Schön zu sehen, wenn jemand auch so denkt...das bestätigt einen dann in seiner Meinung.

Den Link zum Artikel über die Eclipse-Versionierung find ich auch interessant, da könnt ich mich auf meinem Weg mal dran orientieren. War fast schon davon ausgegangen, daß es da scheinbar noch nichts zu gibt...aber lieber mal fragen, nachdem ja heut schon sovies standardisiert ist.

Wer weiß wann das dann als nächstes doch mal ins Auge gefasst wird, vielleicht einmal für die Business-Leute und einmal für die Software-Entwickler.

Grüße

Flori

[perdian]

Den Link zum Artikel über die Eclipse-Versionierung find ich auch interessant, da könnt ich mich auf meinem Weg mal dran orientieren.

Das dürfte auch das sinnvollste sein.

Wenn man sich, was Struktur und Organisation angeht, etwas abgucken kann, dann als Entwickler eigentlich immer bei großen OpenSource Projekten. Da dort meistens eine ganze Reihe guter Entwickler dran sitzen, wollen die auch eine vernünftige Struktur drin haben (sonst artet die Zusammenarbeit in Chaos aus). Und dann kann man sich ja mal ein paar von den Ideen abgucken.