Archiv verlassen und diese Seite im Standarddesign anzeigen : Versionierung von Software
Hallo erstmal,
also um was es bei meiner Frage geht: man entwickelt Software, und entwickelt diese weiter. Die erste Version nennt man evt. Beta 1.0, fixt ein paar Bugs und nennt sie Beta 1.1, fügt neue Features hinzu und nennt sie Beta 2.0.
Dann ist die Software schon ausgereift, die Version 1.0 Final entsteht.
Und so weiter und so fort..
Jetzt stellt sich mir die Frage, ob es da irgendwelche Standards oder Normen gibt, nach welchen man die Versionsbezeichnungen und Nummern vergibt. Klar, erst Alpha, dann Beta, erst 1.0, dann 1.0 + x usw.. aber nachdem es in der Informationstechnik doch für jede Kleinigkeit Normen gibt, könnte ich mir vorstellen, dass für mein Anliegen auch sowas existiert.
Beim Beispiel ganz oben hab ich die Nummern ja nur so vergeben wie es gerade passt .. beim bugfix die Nachkommastelle angehoben, bei neuen Features die Versionsnummer um eins erhöht.
Ich kann verstehen, wenn hier jetzt Leute sagen, das wäre doch sowas von egal .. doch mich interessiert es einfach.
Falls euch keine normierten Verfahren bekannt sind; wie macht ihr das dann immer?
mfg
Monger
2007-11-11, 18:27:51
Es gibt afaik kein standartisiertes Verfahren, oder zumindest habe ich noch keins in der Praxis erlebt.
Im wesentlichen zählt man eigentlich die Build Nummern durch, d.h. der erste Build ist Nummer 1, und von da aus wird gerade hochgezählt. Alpha, Beta, Final ... das ist eher was fürs Marketing als für den internen Prozess. Der Standard kommt meistens daher, dass man ähnliche Versionsverwaltungstools verwendet, wie z.B. Subversion. Die bieten meist ein bestimmtes Nummernschema an, was man dann üblicherweise übernimmt.
tokugawa
2007-11-11, 18:34:59
Der letzte Poster hat recht bis auf die Bezeichnungen Alpha-Beta, da wage ich etwas zu widersprechen (wobei das wohl abhängig ist davon was für Software man meint). Diese sind schon auch für den Entwicklungsprozess wichtig, allerdings eher aus der Sicht des Projektmanagement und für die QA.
Die letzten Milestones eines Projektes sind in der Regel der Alpha-Milestone (wobei der noch unterteilt werden kann) und der Beta-Milestone (auch der kann unterteilt werden).
Das sind meistens wichtige Milestones wo fix definiert ist, was fertig sein muß (das ist eh bei jedem Milestone so), allerdings ist es oft so dass Alpha und Beta jeweils eine Spezialbedeutung haben in Bezug auf "Komplettheit".
Um es auf Spielesoftware umzulegen: Bei uns heißt "Alpha" dass es zwar content-complete ist (alle Levels da, durchspielbar), aber nicht final und sich noch viel ändern kann, wenn man beim Balancing draufkommt dass einige Dinge spieltechnisch einfach nicht funktionieren. "Beta" heißt dass es soweit final ist, dass nur mehr Bugs gefixt werden, sich aber an Features nichts mehr ändert (außer irgendwas ist ein "Blocker").
Alpha/Beta heißt für uns auch leider meistens "Crunchtime" :), weil der Milestone leider immer viel zu nah ist in dieser Phase.
Im wesentlichen zählt man eigentlich die Build Nummern durch, d.h. der erste Build ist Nummer 1, und von da aus wird gerade hochgezählt.
Und wer zählt die Buildnummern wenn man kein Subversion oder andere Codeverwaltung verwendet?
Eigentlich gibts wirklich keine Vorschrift wie man das benennt. Ein standardisiertes Verfahren wär ja auch unmöglich, wer legt denn bitte fest was ein Bugfix, eine Erweiterung oder ein neues Feature ist? Und wer kontrollierts? ;) Glaub kaum dass die Kunden interessieren würde "Diese Software wurde nach ISO-4711-3 versioniert".
Es gibt Firmen, die haben ihr Produkt mit der Version 12.x.y releast. Also das ist reine Geschmackssache. Version "1.0" trifft halt den Geschmack vieler Entwickler ;)
tokugawa
2007-11-11, 19:01:44
Ah jo, bezüglich Versionsnummern: unsere Buildnummern über die wir auch mit der QA kommunizieren (für Fälle wie "tritt in version XYZ auf") sind auch höchst unterschiedlich.
Beim letzten Projekt hatten wir einfach das Build-Datum als "Build-nummer" auf die man sich beziehen kann.
Beim jetzigen verwenden wir die "Changelist"-Nummer aus dem Configuration-Management-System Perforce.
Im Endeffekt sind die Buildnummern unter anderem für die QA wichtig, da man dann in der exakt gleichen Version versuchen kann den Bug zu reproduzieren.
Es gibt afaik kein standartisiertes Verfahren, oder zumindest habe ich noch keins in der Praxis erlebt.
Doch, das gibt's.
Beim Linux Kernel und bei Gnome ist es Standardisiert.
Die Versionsnummer besteht aus einer Majornummern, Releasnummern und Minornumber.
Z.B. so etwas:
1.2.45
Die erste Zahl ist die Majornummer, die legt große Releases fest.
Die zweite Zahl ist die Releasenummer, bzw. die Zahl, die festlegt ob
das jetzt eine Version in Entwicklung ist oder eine stabile Finale Version.
Eine Gerade Zahl ist z.b. eine Finale Version.
z.b.
1.2.45
Eine ungerade Zahl ist eine Entwicklerversion.
z.B.
1.3.45
Und die dritte Zahl, die Minornumber in der Versionsnummer wird fortwährend hochgezählt um die Entwicklungsschritte, Bugversionen usw. niederzuschreiben, sie selbst legen nicht fest, ob das eine Finale oder Entwickerversion ist, das macht wie schon gesagt die Releasenummer, also die Zahl in der Mitte.
Beispiele:
2.3.1456 = 2. Major Release, bei einem Spiel würde das z.b. "Spielname 2" entsprechen, z.b. Battlefield 2, wäre die Majorzahl eine 1, dann würden wir von Battlefield 1942 sprechen.
Die 2 Zahl sagt aber, daß es sich hier um eine Entwicklerversion handelt, da ungerade.
Und die 3. Zahl, die Minorversion sagt aus, daß es der 1456. Build der Entwicklerversion 2.3 ist.
1.4.13 = 1. Major Release, Finale Version, aber wegen der Minornumber 13, schon die Version mit dem 13. Patch.
Ich denke das ist jetzt klar.
Das Schema ist ein anerkannter Standard in großen Projekten.
Bei Linux wird's wohl aber kein 2.7 mehr geben, die haben das Entwicklungsmodell umgestellt.
tokugawa
2007-11-12, 03:35:01
Doch, das gibt's.
Beim Linux Kernel und bei Gnome ist es Standardisiert.
Die Versionsnummer besteht aus einer Majornummern, Releasnummern und Minornumber.
Z.B. so etwas:
1.2.45
Die erste Zahl ist die Majornummer, die legt große Releases fest.
Die zweite Zahl ist die Releasenummer, bzw. die Zahl, die festlegt ob
das jetzt eine Version in Entwicklung ist oder eine stabile Finale Version.
Eine Gerade Zahl ist z.b. eine Finale Version.
z.b.
1.2.45
Eine ungerade Zahl ist eine Entwicklerversion.
z.B.
1.3.45
Und die dritte Zahl, die Minornumber in der Versionsnummer wird fortwährend hochgezählt um die Entwicklungsschritte, Bugversionen usw. niederzuschreiben, sie selbst legen nicht fest, ob das eine Finale oder Entwickerversion ist, das macht wie schon gesagt die Releasenummer, also die Zahl in der Mitte.
Beispiele:
2.3.1456 = 2. Major Release, bei einem Spiel würde das z.b. "Spielname 2" entsprechen, z.b. Battlefield 2, wäre die Majorzahl eine 1, dann würden wir von Battlefield 1942 sprechen.
Die 2 Zahl sagt aber, daß es sich hier um eine Entwicklerversion handelt, da ungerade.
Und die 3. Zahl, die Minorversion sagt aus, daß es der 1456. Build der Entwicklerversion 2.3 ist.
1.4.13 = 1. Major Release, Finale Version, aber wegen der Minornumber 13, schon die Version mit dem 13. Patch.
Ich denke das ist jetzt klar.
Das Schema ist ein anerkannter Standard in großen Projekten.
Es ist eine Konvention, kein Standard. Sonst täten es wirklich alle verwenden, aber gerade in der Spielebranche wird kaum das Linuxschema verwendet.
Es ist eine Konvention, kein Standard. Sonst täten es wirklich alle verwenden, aber gerade in der Spielebranche wird kaum das Linuxschema verwendet.
Nein, es ist ein Standard, das was du meinst wäre eine Norm.
tokugawa
2007-11-12, 03:52:16
Nein, es ist ein Standard, das was du meinst wäre eine Norm.
Norm und Standard sind äquivalente Begriffe. Denk mal nach was "Norm" auf Englisch heißt, bzw wie die Internationale oder auch die US-amerikanische Normierungsbehörde heißt.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.