[Programmvorstellung] ~FM 4.1~

[Manuel]

Uhm... Das wär das Gleiche, als wenn man ein Schachspiel vorstellen würde, bei dem man die Figuren auf JEDES Feld ziehen könnte... Wenn man da einfach sagen würde:

Alle deine Fehler sind nicht normal, wer das Programm richtig bedient, der hat diese Fehler auch nicht.
[...]
Also gibts nix zu verbessern.

...

Da würde es (berechtigte!) Kritik wohl nur so hageln... Nicht übelnehmen, aber jedes noch so gutes Programm (völlig egal ob kommerziell oder kostenlos) würde KEINE weite Verbreitung erfahren, wenn man DAU*-Fehler einfach so abweisen würde...

Dann noch eine kleine Nebensache, die jensma mit der Versionsnummer meint: Normalerweise finden solche Versionssprünge, wie du sie mit deinem Programm gemacht hast, in einem wesentlich kleinerem Maße statt. Das soll jetzt keine Kritik an sich sein, schließlich wird es jedem freien Programmierer überlassen, sein Programm selbst zu "Versionieren"... Trotzdem halten sich geschätzte 90% aller Programmierer an Regeln, wie sie mit Versionsnummern verfahren und die werden in der Regel deswegen eingehalten, weil durch eine Versionsnummer (möglicherweise auch mit "Alpha/Beta/RC/Final"-Zusatz) ersichtlich wird, in welchem Maße das Programm bereits fertig ist und ob man es bereits sinnvoll nutzen kann. Falls ich das Interesse geweckt habe, empfehle ich den Wikipedia-Eintrag unter "Versionsnummer". Hier mal ein kleiner Ausschnitt, wie die Mehrzahl aller Programmierer mit Versionsnummern umgeht:

Eine Versionsnummer setzt sich häufig wie folgt zusammen:

Hauptversionsnummer.Nebenversionsnummer.Revisionsnummer-Buildnummer
[...]

• Eine Hauptversionsnummer (major release) indiziert meist äußerst signifikante Änderung am Programm – z. B. wenn das Programm komplett neu geschrieben wurde (z. B. GIMP 1.x nach 2.x).
• Eine Nebenversionsnummer (minor release) bezeichnet meistens die funktionelle Erweiterung des Programms.
• Eine Revisionsnummer (patch level) enthält meist Fehlerbehebungen.
• Die Buildnummer (build number) kennzeichnet in der Regel den Fortschritt der Entwicklungsarbeit in Einzelschritten, wird also z. B. bei 0001 beginnend mit jedem Kompilieren des Codes um 1 erhöht. Version 5.0.0-3242 stünde also für das 3242. Kompilationsprodukt einer Software.

[...]
Oftmals ist es – vor allem bei Open-Source-Lösungen – der Fall, dass sich die Versionsnummern von Programmen oder Systemen noch vor der Version 1.x befinden. Dies deutet jedoch nicht zwingend darauf hin, dass die Entwicklung noch nicht weit fortgeschritten ist, sondern eher, dass die Version noch nicht das von den Entwicklern gesteckte Ziel erreicht hat und sich weiterhin in der Entwicklung befindet. Teilweise gibt es sogar Open-Source-Programme, die, obwohl sie den Alpha- und Beta-Status längst verlassen haben, weiterhin noch unterhalb der Version 1.x versioniert sind.

...

Natürlich muss die Versionsnummer nicht gleich durch vier (oder mehr) Zahlenreihen bestehen, viele Programmierer beinhalten lediglich zwei Reihen, was auch völlig in Ordnung ist. Der Knackpunkt ist folgender: Wenn du die allererste Zahl in deiner Version schon mit einer "vier" beschreibst, geht - gemäß der groben Richtlinien - jeder davon aus, dass dein Programm schon enorm weiterentwickelt wurde und zig Verbesserungen gegenüber einer "1.0"-Version enthält. Wenn du allerdings - das ist ernst gemeint, keine Beleidigung o.Ä. - noch nichtmal DAU-Fehler ausgebessert hast, wäre eine Version kleiner 0 eher angebracht (ich verweise nochmal auf den Wikipedia-Artikel)...

EDIT:
@dead_orc: Ich hab mich falsch ausgedrückt, ich meinte eine Versionsnummer, bei dem die erste Zahl der Zahlenreihe auf 0 steht :P

* DAU = Dümmster anzunehmender User. In der Regel wird einem beim Programmieren beibebracht, dass derjenige, der das Programm bedient, ein möglicher DAU sein kann (das ist NICHT derjenige, der das Programm programmiert!) und man das Programm möglichst DAU-Sicher machen sollte... Nicht umsonst bringt das Durchtesten des Programms auf Fehler einen nicht unterschätzenden Zeitaufwand mit sich...