Versionen?

Guten Tach
Also mich beschäftig die Frage schon lange wie zählt man eigentlich eine Version eines Browsergames oder auch andere Programme.
Ich meine wie kommt Alcohol 120% auf die Version v1.9.5.4327 wen es mit 1 angefangen hat? und vorallem gibt es ja dann noch so Buchstaben wie Webspell v4.00.01a
Wikipedia konnte mir da net wirklich helfen aber ich hoffe das ihr mir soviel wie möglich über Version Zähler sagen könnt.
Achso noch eine kleine Frage wo liegt der unterschied zwischen Alpha & Beta

de.wikipedia.org/wiki/Versionsnummern
da ist doch eine wirklich gute beschreibung
kurz zusammengefasst:
Produktversion -> Nebenversion -> Patch Level (fällt mir jetzt auch nix besseres ein) -> kompilierung.
- Die Produktversion bezeichnet meistens eine komplette neue Produktversion, dh. es wird meistens nach einem kompletten Recode nur erhöht.
- Die Nebenversion bezeichnet meistens Änderrungen an der Software die neue Features und/oder änderrungen ander Funktionsweise betreffen
- Der/das Patch Level bezeichnet meistens Bugfixes an Neben- oder Produktversionen
- Die letzte Nummer besagt meistens wie oft die Software komplett kompiliert wurde.
Bei Browsergames werden oft die letzten 2 Nummern weg gelassen und durch a, b, c oder ähnliches ersetzt.

Alpha=1.Testversion, noch lange nicht alles drin
Beta=weitere Testversionen, das wichtigste ist drin
RC=Vorabversion, alles drin, auch Bugs *g*
Release=alles drin, hoffentlich keine Bugs...

Versionsnummern sind nur Klang und Rauch.
Jeder kann Versionsnummern festlegen wie man möchte.
Manche Projekte springen gleich von 1.5 auf 6.0, da sich ja soviel getan hatte,
Linux gurkt momentan auf 2.6.17.irgendwas herum, sie haben 4 stellige Versionsnummern.
Tex hat sich zum Ziel gemacht gegen Pi zu streben. Der Nachfolger von 3.14 ist die 3.141. Davon der Nachfolger 3.1415
DirectX wurde von Version 3 auf Version 5 gehoben. Die Version DirectX 4 fiel aus. Das gleiche gilt für Winamp.
Der Regelfall ist die Beschreibung wie sie SpeedyGTD genannt hat. Dies wird auch von MS und anderen großen Softwareherstellen empfohlen.
Der Linux-Kernel besitzt eine leicht andere Nummerierung:
2.6.17.4
2 = Große Versionsänderung
6 = Fundamentale Versionsänderung (neuer Scheduler, etc)
17 = Neue Features wie Treiber oder Parameteränderungen
4 = Securityfix und Fix von Inkompatibilitäten (ich meine dass der Maintainer mal was gesagt haben sollte, dass Patches > 50 Zeilen bei den kleinen Änderungen nicht angenommen werden).

Der folgende Text wurde mir von einem befreundeten Programmierer zur Verfügung gestellt um die Regeln etc. in meinem eigenen Projekt zu verwenden.
Inhaber und Autor ist Martin Baute.
Ausschnitt aus meinen Konzeptunterlagen:
[SIZE=16]2. Versionierung[/SIZE]
2.1 Vorwort
Ich hätte eine Liste von Regeln niederschreiben können. Tatsächlich habe ich das zunächst getan, aber das Ergebnis war ein trockenes, deprimierendes Stück Juristendeutsch. Also schrieb ich statt dessen ein Tutorial, das mit den ersten Quellcode-Dateien beginnt und mit der Pflege mehrerer Entwicklungszweige eines komplexen Produktes endet. Dank gilt den Entwicklern bei Amiga Inc. (1982-1984), denn dieses System ist durch AmigaOS inspiriert.
Einiges, was folgt, geht über reine Versionierung hinaus, in den Bereich der Release-Politik. An einigen Stellen werde ich ein bißchen über den status quo schimpfen, an anderen stellen werde ich stillschweigend ein Vorgehen vorstellen, das auf den ersten Blick merkwürdig erscheinen mag, ohne groß auf das "warum" einzugehen. An diesen Stellen würde ich kein Ende finden, wenn ich erst mit dem Schimpfen anfange.
Zum Beispiel sind Versionen vor 1.0 nicht für die breite Öffentlichkeit bestimmt, und ich muß mir sehr auf die Zunge beißen, um nicht meine ungeschminkte Meinung zu "public betas" kundzutun, die meiner Meinung nach nicht einmal gut genug für eine Alpha wären, oder zu solchen Produkten, die auf ewig pre-1.0 bleiben, weil ihre Autoren sie für "stabil genug" halten.
(Atmen. Entspannen. Atmen. Fokus. Ja, so ist's besser. )
2.2 Software != System
Wenn Sie ein Papier über Versionierung lesen, wollen Sie wahrscheinlich ein Versionskontrollsystem (VCS) einsetzen. CVS, Subversion, PVCS, ClearCase... alles großartige Hilfsmittel, aber keines davon ist ein *System*. Keines von ihnen ermöglicht es festzustellen, welche Quelldateien in ein gegebenes Programm eingeflossen sind. Um dies zu erreichen, braucht es ein *System* zusätzlich zur reinen Software.
Tatsächlich braucht es nicht ein, sondern drei Versionssysteme:
für die Quelldateien (exe/main.c, lib/my_func.c, doc/chapter5.xml);
für die Komponenten (MySoft.exe, MySoft_Manual.pdf, MySoft.lib);
für das Produkt (die Anwendung MySoft).
In den folgenden Kapiteln werde ich ein integriertes System beschreiben, von dem ich hoffe, daß es die Pflege für Anwender, Tester und Entwickler gleichermaßen vereinfacht.
2.3 Anfänge
Sie haben ein kleines Program für den Eigengebrauch geschrieben. Es besteht aus einer Zahl Quelldateien. Nach einigen Revisionen stellen Sie fest, daß es Zeit ist, die Quellen unter Versionskontrolle zu stellen.
Vielleicht haben Sie bereits VCS-Software auf Ihrem System im Einsatz, und ein weiteres Repository ist eine einfache Sache. Vielleicht eröffnen Sie ein weiteres Project auf SourceForge. Vielleicht ist Versionskontrolle etwas völlig Neues für Sie, und Sie müssen sich die Grundlagen erst noch aneignen - in diesem Fall würde ich Ihnen Subversion empfehlen. Es hat ein "traditionelles" Interface, ist was ebenso gut unterstützt wie das weitverbreitete CVS, aber einfacher zu benutzen, skaliert sehr gut, und ist trotz niedriger Komplexität CVS weit überlegen in der Behandlung von Entwicklungszweigen und Tags.
Wie auch immer, das erste was Sie tun sollten (nachdem Sie Ihr VCS aufgesetzt haben), ist, jeder Textdatei in Ihrem Projekt - Quellcode, Makefile, Dokumentation - eine Zeile mit dem String $Id$ hinzuzufügen - oder was auch immer Ihre Software statt dessen benutzt. Wenn möglich, machen Sie daraus die erste Zeile jeder Datei. Das VCS wird dieses Schlüsselwort bei jedem Checkout in einen Statusstring umwandeln, der üblicherweise Dateiversion, -name, -datum und den Username des letzten Bearbeiters enthält. Das hilft dabei, Dateien zuzuordnen, die auf Ihrer Festplatte oder (als Ausdruck) Ihrem Schreibtisch herumfliegen.
In unserem System werden wir diesen Id-String jedoch schlicht ignorieren. Das Format unterscheidet sich von VCS zu VCS, was ihn für ein übergreifendes System unbrauchbar macht. (CVS hält z.B. für jede Datei eine Version im Format major.minor, während Subversion eine globale Revisionsnummer für das ganze Repository hält.)
Aber Ihre Dateien sind jetzt unter Versionskontrolle, und Sie können die Fähigkeiten Ihres VCS nutzen, um... all das zu tun, was Ihr VCS unterstützt. (Lesen Sie das Handbuch!) Sie haben den ersten Schritt getan.
2.4 Komponenten
Eine Anzahl Quelldateien stellt eine Komponente dar. Mehrere C-Dateien und ein Makefile bauen ein Programm, oder eine Bibliothek. Mehrere TeX-Dateien und ein Makefile bauen eine Dokumentation. Wenn wir eine Komponente betrachten, müssen wir in der Lage sein herauszufinden, welche Quelldateien in welcher Version benutzt wurden, um die Komponente zu bauen. Wir müssen auch in der Lage sein, alle Dateien, die für den Bau der Komponente benötigt werden, in der richtigen Version mit einem einzelnen Befehl aus dem Repository zu beziehen.
Die Dateiversionen, die automatisch vom VCS zugewiesen werden, sind hierfür wertlos. Sie unterscheiden sich von VCS zu VCS, und können aus der Komponente nicht ausgelesen werden. Statt nun die einzelnen Dateiversionen irgendwie in die Komponente zu schreiben, machen wir es genau andersherum: Wir vergeben eine Versionsnummer an die Komponente, und "taggen" die zum Bau verwendeten Quelldateien mit eben dieser Komponentenversion.
Wenn Sie Ihr erstes Release unter Versionskontrolle compilieren, erhält jede Komponente die Version 1.0. Jetzt haben Sie zwei Probleme:
wie bekommen Sie die Versionsnummer in die Komponente, so daß sie ausgelesen werden kann?
wie bekommen Sie die Versionsnummer in die einzelnen Quelldateien, so daß diese - und nur diese, in ihrer aktuellen Version - markiert sind als die Bausteine der Komponente 1.0?
Die Antwort lautet, natürlich, "das hängt davon ab", und zwar von der Software, die Sie benutzen. So ziemlich jedes VCS unterstützt das "tagging" von Quelldateien, und das ist es, was wir an dieser Stelle nutzen werden. Wenn Sie Version 1.0 von MySoft.exe compilieren, taggen Sie jede beteiligte Quelldatei mit "MySoft.exe 1.0". Finden Sie heraus, wie Sie Ihrem VCS sagen, "gib mir alle Quelldateien mit diesem Tag". Fügen Sie jeder Quelldatei eine zweite Kommentarzeile hinzu, direkt unter dem $Id$ (oder was Ihr VCS statt dessen verwendet), die vom VCS beim Checkout mit dem verwendeten Tag erweitert wird. Hier ist etwas Studium Ihres VCS-Handbuchs gefragt.
Wenn das so weit eingerichtet ist, haben Sie den schwersten Teil überstanden. Versprochen.
2.5 CVS
CVS verwendet $Revision$ für die Dateiversion, oder $Id$ für einen ausführlicheren Text mit Dateipfad, Version, Datum, Autor und Status. Mit 'cvs tag' wird ein Verzeichnis oder eine einzelne Datei mit einem Tag versehen, und dieses Tag läßt sich in der Quelldatei mit $Name$ anzeigen.
2.6 Subversion
Subversion verwendet $LastChangedRevision$ für Dateiversionen (oder vielmehr die globale Revisionsnummer der letzten Änderung an der Datei, so daß die Nummern nur dann aufeinander folgen, wenn die Datei bei jedem Checkin verändert wurde). Subversion verwendet keine Tags, sondern ermuntert dazu, "Snapshot-Kopien" des Arbeitsverzeichnisses (/trunk) in einen eigenen Dateibaum (/tags) zu machen, mit Hilfe von 'svn copy'. In diesem Fall ist der Name des Unterverzeichnisses das "Tag". (Sie sollten wirklich das Handbuch lesen!) Das Schlüsselwort $HeadURL$ gibt Ihnen den vollständigen Pfad der Datei, inklusive dem Namen des Unterverzeichnisses.

2.7 Pre-Release
Das im letzten Kapitel gesagte erlaubt es, Dateien sehr viel häufiger einzuchecken, als die zu "taggen". Wenn mehr als eine Person an dem Projekt arbeitet, sollte man alle nicht "getagten" Dateiversionen schlicht ignorieren. Sie sind work-in-progress von jemand anderem; die letzte "sichtbare" Version ist die letzte "getagte" Version. (ClearCase unterstützt dies direkt, indem es zwischen mehreren "Tasks" unterscheidet, die sich gegenseitig nicht sehen können solange die Änderungen nicht "öffentlich" gemacht wurden.) Wenn Sie in einem team arbeiten, legen Sie einen Modus Operandi fest, der konkurierende Änderungen regeln (wenn mehrere Entwickler an derselben Datei arbeiten, oder denselben Tag verwenden wollen). All dies hängt wiederum von den Fähigkeiten ihres VCS ab, die Sie selbst herausfinden müssen, aber es ist wahrscheinlich eine gute Idee, eien Komponente mit einem "weichen Lock" zu belegen, bevor man mit der Arbeit beginnt, so daß man informiert wird, wenn die Quellen bereits von jemand anderem bearbeitet werden.
Immer, wenn Ihre Arbeit einen stabilen Punkt erreicht hat, legen Sie ein Tag an. Haben Sie keine Hemmungen, viele Tags anzulegen, besonders in der Pre-Release-Phase. Zu viele Änderungen zwischen zwei Tags machen einen 'diff' zwischen den Tags nutzlos. Ein typischer Changeset sollte ein einzelnes Problem betreffen, das mit einem Satz beschrieben werden kann (dem Checkin-Kommentar), und ggf. einen Update der Dokumentation beinhalten. (Heben Sie sich das nicht für später auf, den "später" bedeutet "nie".) Die Quellen sollten ohne Warnungen compilieren und die automatischen Tests bestehen. (Sie verwenden automatisch bei jedem Checkin laufende Testtreiber, oder etwa nicht?)
Wenn ein Checkin-Kommentar nicht auf alle Dateien in einem Changeset zutrifft, oder nicht alle gemachten Änderungen umfaßt, ist Ihr Changeset schlecht. Dies erfordert Erfahrung. Wenn Sie ein Problem B entdecken während Sie an Problem A arbeiten, machen Sie eine Notiz (im Bug Tracker vielleicht?), und erstellen ein neues Changeset B nachdem Sie mit dem für Problem A fertig sind.
Entschuldigen Sie das Oberlehrer-Gehabe, aber es ist wichtig. Wenn Sie sich hier nicht unter Kontrolle halten, sinkt die Nützlichkeit eines VCS rapide.
Diese häufigen "Zwischentags" erhöhen grundsätzlich die "minor"-Versionsnummer der Komponente - 1.1, 1.2, 1.3 und so weiter.
2.8 Product Build
Jetzt haben Sie also eine Sammlung von Komponenten, und stellen sie zum ersten Mal zum größeren Produkt zusammen. Obwohl Ihre Komponenten ihre individuellen tests durchlaufen haben (Sie verwenden automatische Testtreiber, oder etwa nicht?), ist das Produkt als Ganzes immer noch ungetestet. Also, und obwohl die Komponenten die Version 1.x tragen, trägt das Produkt die Version 0.1.
Dies ist ein wichtiger Punkt in diesem System. MySoft.exe 1.27, MySoft_Manual.pdf 1.8 und MySoft.lib 1.31 stellen MySoft 0.1 dar. Sehr wahrscheinlich werden Sie weiter an MySoft arbeiten. Irgendwann wird es ein MySoft 0.2 geben. Also werden, wenn Sie Ihre Quellen das erste Mal nach dem Product Build "taggen", die "major"-Version hochgesetzt und die "minor"-Version auf 1 zurückgesetzt.
Der erste Schritt zu MySoft 0.2 sind daher MySoft.exe 2.1, MySoft_Manual.pdf 2.1, und MySoft.lib 2.1. Die "minor"-Versionen werden wahrscheinlich ein paar Mal iterieren, bevor MySoft 0.2 ferig ist, aber Sie haben soeben die Produktversion 0.1 mit den Komponentenversionen 1.x "verbunden". Eine 2.x-Komponente gehört nicht zu einem 0.1-Produkt. Wenn Ihnen jemand ein Problem mit MySoft 0.1 mitteilt, weil MySoft.lib 2.14 eine Exception wirft, wissen Sie, daß das Problem in einem fehlgeschlagenen Update o.ä. zu suchen ist.
Im Fall, daß eine Komponente sich zwischen zwei Versionen von MySoft gar nicht ändert, müssen Sie trotzdem die "major"-Version hochsetzen - für diesen Fall ist 2.0 (statt 2.1) reserviert. Das ist etwas trickreiche und implizite "Verschlüsselung" von Information, aber ich finde die Idee ansprechend. Wenn Sie es nicht mögen, lassen Sie es. Die enthaltene Information ("seit der letzten Version von MySoft nicht verändert") ist ohnehin marginal.
Mit diesem Vorgehen kommen Sie bequem durch die Pre-Release-Phase von MySoft. Die Dinge werden etwas komplizierter, sobald Sie mit MySoft 1.0 an die Öffentlichkeit gehen...
2.9 Alpha - Beta - Release - Patch
Machen wir einen Sprung in die Zukunft. MySoft ist an die Öffentlichkeit gegangen. Version 1.6 liegt frisch in den Regalen (bestehend aus Komponenten mit der Version 30.x), und der Erfolg ist riesig. Einige Mitentwickler helfen Ihnen bei der Weiterentwicklung.
Wie üblich wenn ein neues Release gebaut wurde, setzen Sie die "major"-Version Ihrer Komponenten beim nächsten Tag auf 31.x. Leute, die MySoft intensiv genug einsetzen, um sich für die Versionen der Komponenten zu interessieren, werden wissen, daß 31.x-Quellen oder Komponenten zu einer zukünftigen Produktversion gehören, selbst wenn sie ihnen einzeln begegnen sollten. (Ihre Mitentwickler sollten das auch wissen...)
Nach ein paar Änderungen sind Sie mit dem Ergebnis zufrieden. Sie bauen ein neues MySoft-Package. Natürlich ist die nächste logische Version die 1.7, aber diese haben Sie noch nicht getestet. Wie verhindern Sie, daß Kunden sich auf etwas stürzen, was sie für das nächste Release ihrer Lieblingssoftware halten, und dabei über jede Menge unentdeckter Fehler stolpern?
2.9.1 Alpha
Die Antwort ist "1.7 alpha 1". Alpha teilt mit, daß es sich um einen internen Snapshot für Entwickler handelt, keine Garantien, Finger weg wenn man kein MySoft-Entwickler ist. Die Nummer hilft dabei, ein paar kleinere Patches vor einer 1.7-Release anbringen zu können.
Ihre Mitentwickler testen 1.7 alpha 1, und entdecken ein paar kleinere Fehler (oder haben Verbesserungsvorschläge). Änderungen werden vorgenommen (und die "minor"-Versionen der Komponenten entsprechend angepaßt), und eine neue Version von MySoft wird gebaut - "1.7 alpha 2".
2.9.2 Beta
Diese Version ist besser, Ihre Mitentwickler heben nach ein paar Wochen Test den Daumen. Ohne irgendwelche Änderungen vorzunehmen, geben Sie der "1.7 alpha 2" das Tag "1.7 beta 2". (Achten Sie darauf, die Nummer hinter dem alpha / beta nicht zurückzusetzen, um die Information zu erhalten, das alpha 2 und beta 2 tatsächlich identisch sind.) Sie geben diese Version an eine ausgesuchte Gruppe von Betatestern (und Early Adopters), um sie unter Einsatzbedungungen zu testen und vielleicht noch ein paar selten auftretende Fehler zu entdecken.
Ich persönlich habe etwas gegen "Public Betas", den sie werden dem Begriff "Betatester" nicht gerecht. Ein Betatester ist sehr viel mehr als jemand, der eine Software auf seinem System einsetzt und auf Fehler gefaßt ist. Ein Betatester unterzieht eine Software allen möglichen und unmöglichen Bedingungen; er verfolgt Fehlverhalten bis zur kleinsten Abfolge von Handlungen, die das Fehlverhalten reproduzieren; er stellt einen Report in Ihren Bug Tracker ein. Es ist eine ganz besondere Qualifikation, in keiner Weise der eines Entwicklers unterlegen. Gute Bug Reports helfen Ihren Entwicklern, Fehler schnell zu finden und zu beheben, und verbessern erheblich die Qualität Ihres Produkts. Gute Betatester sind ein Gewinn für das Projekt. "Public Beta" impliziert, daß jeder gut genug ist, ein Betatester zu sein; das ist nicht der Fall, und Ihr Bug Tracker wird entweder leer bleiben, oder von Reports überfließen, die Ihnen nicht weiterhelfen. Sagen Sie nicht, ich hätte Sie nicht gewarnt.
Wenn ein Betatester einen Fehler findet, der einen Release von 1.7 beta 2 unmöglich macht, beheben Sie den Fehler in Ihren Quellen, passen dabei die "minor"-Version der betroffenen Komponenten an, und bauen daraus 1.7 alpha 3. Wenn die Änderungen wirklich minimal sind, wie z.B. Schreibfehler, können Sie statt dessen direkt eine 1.7 beta 3 bauen und die Alpha-Phase überspringen - aber seien sie vorsichtig, jede Beta-Release bedeutet eine Menge ermüdende Arbeit für Ihre Betatester.
2.9.3 Release
Eines Tages wird eine Beta den "Daumen hoch" von Ihren Betatestern bekommen, und sie "taggen" diese Beta als 1.7, fertig für die Veröffentlichung.
Wenn Sie nicht Open Source entwickeln, werden Ihre Anwender grundsätzlich nur Versionen im Format major.minor sehen. Wenn Sie Open Source entwickeln, werden sie wissen, daß sie besser die Finger von allem lassen, bei dem auf major.minor noch etwas folgt.

2.9.4 Patch
Dann ist da die Sache mit der Versionspflege. Einfach den Kunden zu sagen, immer auf die neueste Version zu aktualisieren, ist keine gute Art, mit Problemen in älteren Versionen umzugehen, zumindest nicht bei komplexen Produkten wie Betriebssystemen, Compilern usw. - es mag Probleme mit der Abwärtskompatibilität geben, oder das Update ist zu aufwendig, um für den Kunden in Frage zu kommen. Fazit, Sie werden vielleicht Version 1.6 auch nach dem Release der 1.7 noch unterstützen wollen.
Wieder entscheiden die Fähigkeiten des von Ihnen eingesetzten VCS, wie Sie die Dinge auf unterster Ebene handhaben. Vielleicht richten Sie mit jedem Release einen Entwicklungszweig ein. Was die Versionierung angeht, nun, die Komponenten 30.x sind immer noch da, und an ihnen müssten zukünftige Patches für Produktversion 1.6 vorgenommen werden. Evtl. ist es eine gute Idee, ein Tag "MySoft 1.6" an die beteiligen Komponenten der 30.x-Gruppe hinzuzufügen, so daß Sie nicht nach den einzelnen beteiligten Komponentversionen suchen müssen. Sie brauchen aber in jedem Fall zusätzlich zu "MySoft 1.6" noch den Komponenten-Tag, oder Sie wissen nach dem Path nicht mehr, daß die bearbeitete Komponente z.B. MySoft.lib 30.14 war und das neue Tag MySoft.lib 30.15 lauten muß.
Was die Versionierung der Patches angeht... AmigaOS bot ein Binary namens "SetPatch" an, die alle Patches für alle Versionen des Betriebssystems enthielt. Egal ob man AmigaOS 2.1 oder 3.0 oder welche Version auch immer einsetzte, solange man beim Boot das neueste SetPatch ausführte, hatte man die neuesten OS-Patches installiert. Es war die eine Komponente, die man *immer* in der höchsten Version einsetzte, selbst wenn die "major"-Version nicht zum restlichen System paßte. Ich persönlich mag diesen Ansatz, weil er nicht nur die Pflege (und die Suche nach neuen Patches) vereinfacht, sondern auch Entwickler dafür sensibilisiert, wieviel man in einen Patch hineinquetscht und ab wann ein neues Release besser wäre.
Sie können diesen Ansatz übernehmen, oder eine "Patch-Komponente" der Version hinzufügen. In diesem Fall müssen Sie den "Patchlevel" des Produkts MySoft ausweisen - z.B. als "MySoft 1.6 patch 3" oder so ähnlich. Da es recht üblich ist, daß selbst große Projekte alte Releases aufgeben sobald ein neues Release gemacht wird, gehe ich hier nicht weiter ins Detail.
2.10 Der 1.0 Release Rant
"Veröffentliche früh, veröffentliche oft" ist der Leitspruch der Open-Source-Entwicklung. Ich halte dieses Konzept für grundlegend fehlerhaft.
Während Projekt-Maintainer häufige Public Releases als einen Weg sehen, die Software durch häufigeren Feedback schneller fortentwickeln zu können, verwässert es doch die Nachricht, die dem Anwender durch die Versionsnummer mitgeteilt wird. Auf der einen Seite werden pre-1.0-Versionen als Lösung für Alltagsprobleme angepriesen (z.B. OpenSSH oder OpenSSL), und vom Anwender wird erwartet, daß er solche pre-1.0-Versionen an kritischen Stellen in seinem System akzeptiert. Auf der anderen Seite werden Klagen über Fehler oder schlechte Funktionalität häufig mit einem arroganten "es ist pre-1.0, was erwartest Du?" abgebügelt.
Entweder ist ein Produkt reif für die Öffentlichkeit (1.0 oder später), oder es sollte nicht für die Öffentlichkeit paketiert werden (außerhalb einer Public Beta). Eine Public Beta wiederum ist nicht die Lösung für ein produktives Problem, sondern eine Aufgabe für die Person, die sie einsetzt.
Manche Maintainer glauben daß eine 1.0 irgendwie alle Funktionen enthalten müßte, die man sich für ein soclhes Produkt nur vorstellen kann. Das ist Unsinn. Setzen Sie sich realistische Ziele für Ihre 1.0-Release. Machen Sie sich Notizen, welche Funktionen für spätere Versionen reserveirt sind. Implementieren Sie eine funktionale Untermenge Ihrer Träume, und veröffentlichen Sie Ihre 1.0 mit einer Liste unerledigter Punkte. Oder noch besser, veröffentlichen Sie Ihre 1.0 ohne eine solche Liste, und überraschen Sie die Anwender Ihrer 1.0 mit tollen Funktionen über tollen Funktionen in folgenden Releases. Das erzeugt eine sehr viel bessere PR als ewig pre-1.0-Versionen zu veröffentlichen, weil man im eigenen Kopf die 1.0 für das persönliche Software-Utopia reserviert hat.
2.10.1 Die Garantie einer 1.0
Die Version 1.0 eines Produktes zu veröffentlichen ist eine Garantie, die man dem Anwender gibt: Ihr Produkt tut, was von ihm behauptet wird. Es ist Dokumentation verfügbar, vollständig und auf aktuellem Stand. Die Software wurde eingehend getestet und verhält sich Fehlertolerant. Sie haben vor, für eine angemessene Zeit Support für diese Version zu leisten, vor allem, wenn spätere Versionen nicht mehr kompatibel sein sollten.
Auf der anderen Seite weiß der Anwender, daß eine pre-1.0 nicht wirklich für den Alltagseinsatz gedacht ist, und spektakuläres Fehlverhalten an den Tag legen kann. Er weiß auch, daß eine 1.0 immer noch Wünsche offen läßt (die hoffentlich in zukünftigen Versionen erfüllt werden). Er weiß daß er Ihre pre-1.0 auf eigene Gefahr benutzt.
"Moment mal", höre ich die OSS-Leute rufen, "OSS-Software bietet sowieso keine Garantie, denn immerhin wurde ich nicht dafür bezahlt. Sie benutzen meine Software ohnehin auf eigene Gefahr!" Solchen Leuten kann ich nur sagen, ihr seid eine Schade für die Softwareentwicklung, und habt das Konzept nicht begriffen: Anwender werden eure Software herunterladen, weil sie erwarten, daß sie das tut, was von ihr behauptet wird. Vielleicht werden sie euch nicht verklagen, wenn ihr eure Ankündigungen nicht einhaltet, aber sie haben das verdammte Recht, ihren Unmut zu äußern, wenn ihr schlechte Software veröffentlicht.
Wenn man in einer Band spielt, die öffentliche Auftritte hat, ist fehlender Lohn auch keine Ausrede für eine schlechte Performance. Die Leute werden den Saal verlassen, wenn die Performance mies ist. Wer nicht vorhat, gute Qualität abzuliefern, übt das falsche Hobby aus. Versucht Ikebana als künstlerischen Output, der andere Leute nicht ärgert, oder vergrabt euch im Keller, aber erspart anderen Leuten die Mühe, herauszufinden, wie schlecht eure Performance wirklich ist.
Entschuldigung für die harten Worte, aber das kam von Herzen.
2.11 Verschiedenes
2.11.1 1.0 Release
Die 1.0-Release ist etwas besonderes: Sie markiert den Übergang von der fortlaufenden Numerierung der Pre-Release-Phase zum Alpha / Beta / Release-Zyklus. Wahrscheinlich werden Sie die Alpha-, vielleicht sogar die Beta-Phase für 1.0 komplett überspringen wollen, da Sie erhebliche Aufwände in die Tests und Verbesserungen von MySoft 0.1, 0.2, 0.3 etc. gesteckt haben.
Idealerweise wird Ihre 1.0 die am besten getestete, stabilste Release überhaupt sein.
2.11.2 Major Releases
An einem bestimmten Punkt wird ihre Liste unerledigter Punkte Funktionen umfassen, die nicht erreicht werden können, ohne die Abwärtskompatibilität aufzugeben. Die neue Version von MySoft wird weit mehr Funktionen umfassen, aber z.B. werden Scripts für die alte Version nur nach gewissen Anpassungen mit der neuen Version laufen.
Das ist der Grund, aus dem man mit dem nächsten Release die "major"-Version von MySoft erhöht. Nach 1.7 kommt z.B. die Version 2.0 - in Hinsicht auf den Alpha- / Beta-Zyklus bleibt jedoch alles beim Alten.
Der Punkt ist allerdings, das es Leute geben wird, die die Umstellung auf 2.0 nicht mitmachen werden. Vielleicht ist ihnen der Maintenance-Aufwand, alle Scripte überprüfen zu müssen, zu hoch. Vielleicht sehen sie die 2.0 nicht als Verbesserung. (Signifikante Änderungen bergen immer die Gefahr eines Nachlassens in der Qualität.) Vielleicht ist ihnen das Preisschild an der 2.0 die Vorteuile nicht wert.
Diese Leute werden erwarten, daß die 1.x-Serie für einige Zeit weiter gepflegt wird, nicht nur mit kritischen Patches sondern auch mit Backports von neuen Funktionen. Je komplexer Ihr Produkt, desto seltener sollten Sie eine Major Release durchführen.
(Dieser Text bietet keinen Ansatz, wie die Versionierung eines parallelen 1.x / 2.0-Zweiges zu handhaben sei. Bei Gelegenheit erweitern!)

Okay okay ich glaube das sind sehr sehr gute Antworten vielen Dank an alle.

Und dann gibt es ja auch noch
Microsoft (r) Windows Version 5.1 (Build 2600.xpsp_sp2_gdr.050301-1519 : Service Pack 2)

Ha, meiner ist länger:
Microsoft (r) Windows (r) Version 6.0 (Build 5536.16385.x86fre.vista_rc1.060821-1900 : Service Pack 0, v.)
Bzw:
H:\Users\mbrenn>ver
Microsoft Windows [Version 6.0.5536]

Pah, meiner ist noch länger:
Linux version 2.6.17-1.2174_FC5 ([email protected]) (gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)) #1 Tue Aug 8 15:30:55 EDT 2006
more /proc/version

Ist das jetzt der virtuelle Schwanzvergleich? Wer hat den längeren?

klar knalli. meinen zeig ich lieber erst gar nich da werden nur alle neidisch .

@Frost: bei undead steht der Compiler noch nicht dazu