Versionszählung

[Sven]

Moin,

überall werden Versionen gezählt. Seien es Homepages, Scripte oder sogar Programme.

Dann gibt es Firefox 0.8, auf der anderen Seite PHP 4.3.5, und Mozilla 1.6.

Dann liest man auch mal von Alpha, Beta, Gamma und Delta-Versionen, woanders wieder von RC's oder sowas.

Deswegen frage ich: Gibt es irgendein System bei Versionszählung - oder vergleichbares? Irgendeinen Standart?

Gruß,

Sven

[MudGuard]

Hi,

überall werden Versionen gezählt. Seien es Homepages, Scripte oder sogar Programme.
Dann gibt es Firefox 0.8, auf der anderen Seite PHP 4.3.5, und Mozilla 1.6.
Dann liest man auch mal von Alpha, Beta, Gamma und Delta-Versionen, woanders wieder von RC's oder sowas.
Deswegen frage ich: Gibt es irgendein System bei Versionszählung - oder vergleichbares? Irgendeinen Standart?

Nein, noch nicht mal einen Standar_d_.

Die meisten Versionszählungen haben nur eines gemeinsam:
neuere Versionen haben höhere Nummern als ältere.

cu,
Andreas

[Stefan Muenz]

Hallo Andreas,

neuere Versionen haben höhere Nummern als ältere.

Aus dieser Kernaussage solltest du glatt einen RFC machen! ;-)
Aber im Ernst: waere es nicht sinnvoll, mal ein Konzept zu dem Thema Versionierung zu erarbeiten und dieses in Form einer Internet-Draft einzureichen? Mich stoert das Kraut-und-Rueben-Durcheinander bei der Versionenpolitik vieler Produkte naemlich auch. Ich bin auch ziemlich sicher, dass viele OpenSource-Projekte sich selber ein Bein stellen, weil sie viel zu lange mit 0.irgendwas-Nummern auftreten (wie soll jemand, der gewohnt ist, mit MS IE 6.0 zu arbeiten, einen Firefox "0.9.2" ernst nehmen?). Ausserdem sollte mal festgelegt werden, wo die Grenze zwischen "Version" und "Built" ist. Diese Versionsnummern mit zwei, manchmal sogar drei Punkten dazwischen finde ich persoenlich arg gewoehnungsbeduerftig, und man hat staendig das Gefuehl, nicht die aktuellste Version zu haben, weil alle paar Tage eine neue Version mit neuer Endnummer heraus kommt. Andererseits erlaubt das natuerlich eine flexiblere Veroeffentlichungspolitik. Aber ein RFC, in dem mal drin steht: "du darfst nicht mehr als einen Punkt in deiner Versionsnummer verwenden, musst dich, wenn dein Produkt offensichtlich praxistauglich ist, sofort zu einer 1 vor dem ersten Punkt durchringen, du darfst keine Versionsnummern ueberspringen (MS Word bekommt daher 4 Versionsnummern abgezogen), und wenn du mehr als 33,3% des Aufwandes, der in der letzten Version steckte, fuer die neueste aufgewendet hast, muss diese als neue Vollversion deklariert werden - oder so aehnlich. Jedenfalls irgendwas, durch das mal etwas mehr Vergleichbarkeit entstehen wuerde.

viele Gruesse
  Stefan Muenz

[Xava]

[Internet-Draft zu Versionsnr.]

Prinzipiell eine gute Idee. Aber insbesondere im kommerziellen Bereich -- so denke ich -- wird es wohl kaum auf Akzeptanz stossen. Denn die Versionsnr./-namen werden immer öffters als Marketinginstrument missbraucht, wie z. B. die Verwendung von Jahreszahlen parallel zu den normalen Nummern oder dass von dir bereits erwähnte Überspringen von Versionsnr.

Sinnvoll wäre es zu definieren, welche Stelle für was genau steht. So kann trotzdem jeder unterschiedlich lange (bzw. viele Punkte) verwenden. Von links nach rechts sollten dann die Versionsnr. an Wichtigkeit verlieren bzw. nur für wenige Veränderung stehen (wie es ja auch bereits oft üblich ist). So wäre für den Endanwender klar -- egal vieviele Sub-Versionsnr. (Punkte) es gibt, für was bzw. für welchen Grad der Veränderung welche Stelle steht.

Wichtig wäre auch zu definieren, ab wann bzw. welchen Grad der Veränderung die nächste linke Nummer inkrementiert wird.

Mein Vorschlag wäre:

main . new feature(s) . bugfix(es) [ . build . status (alpha, beta, etc. um zu kennzeichnen, dass es keine offizielle Veröffentlichung ist, sondern ggf. nicht fehlerfrei ist) ]

Die erste Nummer ganz links sollte erst dann von "0" auf "1" gesetzt werden, wenn das Programm fehlerfrei und mit allen notwendigen bzw. minimalen Funktionen ausgestattet ist.

"main" ist ein Milestone, und wäre immer dann erreicht, wenn alle für den jeweiligen Milestone geplanten Funktionen implementiert wurden und fehlerfrei funktionieren.

So erhöht sich die zweite Nummer von links ("new feature(s)" für jede neue Funktion(en), die für den nächsten Milestone geplant ist...

Werden bei Projekten/Programmen Versionsnr. von links nicht angegeben, so gibt es hierfür keine Veröffentlichungen.

Will jemand in der mitte keine Versionen veröffentlichen, z. B. keine neuen Versionen für einzelne neue Funktionen, sondern immer nur fertige Milestones und Bugfixes so lässt man die Nummer einfach auf "0" stehen.

Dieses Modell würde ich als logisch ansehen. Und jeder wüsste für was, welche Nummer an welcher Stelle steht und kann Programm-/Projekt-übergreifend für sich entscheiden, ob er die Version installiert/aktualisiert oder nicht.

Das Problem -- wie bereits oben erwähnt -- wird sein, dass sich nicht jeder dran halten wird -- Egal, ob es einen Standard gäbe.

[Daniela Koller]

Hi Stefan

Es gibt solche Regeln für 3stellige Versionsnummern:

1 Stelle: ändert bei sehr grossen Änderungen. Es muss
          also ein grosser Teil des Programmes komplett
          neu geschrieben werden oder neue Funktionen
          hinzugekommen sein, die den grössten Teil des
          Programms ausmachen.

2. Stelle: Neue Funktionalität, mittelgrosse Änderungen,
           Renovation kleinerer Bereiche des Codes.

3. Stelle: Bugfixes, kleinste Features.

Gruss Daniela

[Fabian Transchel]

Hallo Stefan,

(wie soll jemand, der gewohnt ist, mit MS IE 6.0 zu arbeiten, einen Firefox "0.9.2" ernst nehmen?).

Aus diesem Grund bastelt AOL regelmäßig aus den Mozilla-Milestones neue Netscape-Derivate. Netscape 7.2 wird demnach aus Mozilla 1.7 gebastelt. Und nur genau diese Netscapes sind dann für den Heimanwender gedacht. Dass wir alle Mozilla verwenden tut ja nix zur Sache. ;-)

Netscape 7.2 hört sich gegenüber IE 6.0 doch ganz ordentlich an, nicht?

Grüße aus Barsinghausen,
Fabian

[MudGuard]

Hi,

neuere Versionen haben höhere Nummern als ältere.
Aus dieser Kernaussage solltest du glatt einen RFC machen! ;-)

Ich hatte eher an ein Patent gedacht ;-)

Mich stoert das Kraut-und-Rueben-Durcheinander bei der Versionenpolitik vieler Produkte naemlich auch.

Naja, also ich finde es wesentlich wichtiger, daß es detaillierte Auflistungen gibt, was sich von Version zu Version ändert.
Dann kann ich nämlich entscheiden, ob ich updaten will (weil mich mindestens eine der Änderungen interessiert) oder nicht.

Ob da jetzt aber die erste, zweite, siebte oder zweiundvierzigste Zifferngruppe der Versionsnummer geändert wurde, ist für mich zweitrangig.

Ich bin auch ziemlich sicher, dass viele OpenSource-Projekte sich selber ein Bein stellen, weil sie viel zu lange mit 0.irgendwas-Nummern auftreten (wie soll jemand, der gewohnt ist, mit MS IE 6.0 zu arbeiten, einen Firefox "0.9.2" ernst nehmen?).

Seh ich ähnlich.

Ausserdem sollte mal festgelegt werden, wo die Grenze zwischen "Version" und "Built" ist. Diese Versionsnummern mit zwei, manchmal sogar drei Punkten dazwischen finde ich persoenlich arg gewoehnungsbeduerftig, und man hat staendig das Gefuehl, nicht die aktuellste Version zu haben, weil alle paar Tage eine neue Version mit neuer Endnummer heraus kommt.

Wie gesagt: "Was ist neu" halte ich für wichtiger.

cu,
Andreas

[Sven Rautenberg]

Moin!

neuere Versionen haben höhere Nummern als ältere.

Aus dieser Kernaussage solltest du glatt einen RFC machen! ;-)

Mehr kann man in der Tat nicht über Versionsnummern aussagen.

Ich bin auch ziemlich sicher, dass viele OpenSource-Projekte sich selber ein Bein stellen, weil sie viel zu lange mit 0.irgendwas-Nummern auftreten (wie soll jemand, der gewohnt ist, mit MS IE 6.0 zu arbeiten, einen Firefox "0.9.2" ernst nehmen?).

Diese Nullnummern entstehen ganz einfach durch den Zweckpessimismus der Entwickler von Open Source Software - ganz im Gegensatz zum Hurraoptimimus der Entwickler bzw. genauer der Marketingabteilungen kommerzieller Software, bei denen eine faktische Doppelnull-Alpha-Version schon als "1.0" und die darauf folgende Null-BuggyBeta als "1.5" verkauft wird.

Ausserdem sollte mal festgelegt werden, wo die Grenze zwischen "Version" und "Built" ist. Diese Versionsnummern mit zwei, manchmal sogar drei Punkten dazwischen finde ich persoenlich arg gewoehnungsbeduerftig, und man hat staendig das Gefuehl, nicht die aktuellste Version zu haben, weil alle paar Tage eine neue Version mit neuer Endnummer heraus kommt.

Wenn das mit den Versionen so einfach wäre...

Grundlage fast jeden Softwareprodukts sind mehrere Quelltextdateien, welche in einer Versionsverwaltung stecken, welche je Datei einzeln Versionsnummern vergeben kann. Insofern ist das erstellte Produkt dann ein Mischmasch aus diversen Versionen der Quelltexte und kriegt seinerseits wieder eine (teils gewollte, teils logisch hochgezählte) Versionsnummer.

Und wenn man, wie beispielsweise bei Windows, ein komplexeres System aus diversen Subsystemen zusammensetzt, dann ist hinsichtlich der Versionsnummer wohl tatsächlich Wunschkonzert angesagt.

Aber ein RFC, in dem mal drin steht: "du darfst nicht mehr als einen Punkt in deiner Versionsnummer verwenden, musst dich, wenn dein Produkt offensichtlich praxistauglich ist, sofort zu einer 1 vor dem ersten Punkt durchringen, du darfst keine Versionsnummern ueberspringen (MS Word bekommt daher 4 Versionsnummern abgezogen), und wenn du mehr als 33,3% des Aufwandes, der in der letzten Version steckte, fuer die neueste aufgewendet hast, muss diese als neue Vollversion deklariert werden - oder so aehnlich. Jedenfalls irgendwas, durch das mal etwas mehr Vergleichbarkeit entstehen wuerde.

Es gibt ja so viele Zählschemata.

PHP nutzt drei Stellen, und zusätzlich noch die Kennzeichnung alpha, beta und RC (release candidate), jeweils wieder durchnumeriert. Da gibts also z.B. "4.3.8" und "5.0.0 RC2" (und außerdem eine Funktion, die Versionsnummern auf "größer/kleiner" vergleichen kann).

Der Linux-Kernel nutzt auch dreistellige Versionsnummer, allerdings ist hierbei die zusätzliche Bedingung, dass die zweite Stelle anzeigt, ob es sich um einen Entwicklerkernel, an dem neue Features ausgetestet werden, handelt (ungerade Nummer), oder um einen Produktivkernel für den breiten Einsatz in den Systemen (gerade Nummer).

Opera hat im Prinzip auch drei Stellen, aber der zweite Punkt wird weggelassen. So gibt es denn also einen Opera 7.23, aber der Opera 7.5 ist aktueller, und Opera 7.05 ist ganz alt, aber mit 7.5 keinesfalls identisch.

Die Marketing-Versionsnummern diverser Software hingegen sind reines Wunschdenken und symbolisieren bestenfalls nur noch die Tatsache, dass es sich um ein kleineres Update oder um einen größeren Umbau der Software handelt - wobei letzteres zugunsten der eigenen Kasse gerne mal angenommen wird. Die Idee von Microsoft, die Versionsnummern zugunsten von Jahreszahlen komplett in den Hintergrund zu drängen, verwirrt noch zusätzlich, wenngleich man so recht leicht ablesen kann, dass das ach so beliebte Windows 95 jetzt auch schon neun Jahre alt ist und vielleicht doch mal durch ein Update ersetzt werden sollte. Am besten ein Update auf Linux ;).

- Sven Rautenberg

[Rolf Rost]

Moin,

Deswegen frage ich: Gibt es irgendein System bei Versionszählung - oder vergleichbares? Irgendeinen Standart?

YES sowas gibt es: RCS = Revision Control System

Gruss, Rolf

[Tim Tepaße]

Hallo Sven,

(Ich bin lernfähig, ich falle nur in alte Schemata zurück, wenn Du auch
zurückfällst. ;o)

Deswegen frage ich: Gibt es irgendein System bei Versionszählung - oder
vergleichbares? Irgendeinen Standart?

Nein. Es gibt nur unterschiedliche Traditionen. Die Tradition des Marketings,
das man schneller sehr höhere Versionsnummern verwenden sollte, um sich von
der Konkurrenz zu unterscheiden, die Tradition der Open-Source-Gemeinschaft,
mit sehr niedrigen Versionsnummern zu beginnen und die 1.0 als das angestrebte
Ziel zu bezeichnen.

Und es gibt witzige Traditionen bei Versionsnummern, über die ich mich gestern
noch unterhalten habe:

Das von Donald Knuth entwickelte Textsatzsystem TeX wird als abgeschlosses
Projekt betrachtet. Die Versionsnummer konvergiert gegen Pi, das heißt immer
wenn irgendein Bugfix dazukommt, wird eine weitere Stelle von Pi an die
Versionsnummer herangehängt. Die derzeitige Versionsnummer ist 3.14159

Ebenso strebt das ebenfalls von Knuth entwickelte Programm METAFONT gegen die
Zahl e, die ebenso eine irrationale Zahl ist wie Pi. Derzeitige Versionsnummer
ist 2.7182.

Gerüchteweise soll sich der MP3-Player Winamp für die großen Versionsnummern
bei der Fibonacci-Reihe bedienen. Dann aber nicht sehr konsequent; ich kann
mich jedenfalls nicht an zwei unterschiedliche Versionen 1 erinnern. Aber
man wird sehen, ob der nächste Player nach der Version 5 die Versionsnummer
8 tragen wird. ;o)

Tim

[Sven]

Moin Tim,

Ich bin lernfähig

Das höre ich gerne :))

ich falle nur in alte Schemata zurück, wenn Du auch zurückfällst. ;o)

wunderbar. Dann sind wir uns ja einig ;)

Deswegen frage ich: Gibt es irgendein System bei Versionszählung - oder
vergleichbares? Irgendeinen Standart?
Nein.

Obwohl Rolf in seinem Posting [pref:t=86117&m=508811] geschrieben hat, es gäbe da einen Standard, meinen auf der anderen Seite eine ganze Menge Leute, es gäbe keinen. Ich schließe mich jetzt einfach mal der breiten Masse an, da der
besagte Standart von Rolf, RCS, sich bei Nachfrage bei Wikipedia als irgendein Programm
oder vergleichbares herausstellt; http://de.wikipedia.org/wiki/Revision_Control_System.

Es gibt nur unterschiedliche Traditionen. Die Tradition des Marketings,
das man schneller sehr höhere Versionsnummern verwenden sollte, um sich von
der Konkurrenz zu unterscheiden, die Tradition der Open-Source-Gemeinschaft,
mit sehr niedrigen Versionsnummern zu beginnen und die 1.0 als das angestrebte
Ziel zu bezeichnen.

aha.

Und es gibt witzige Traditionen bei Versionsnummern, über die ich mich gestern
noch unterhalten habe:
Das von Donald Knuth entwickelte Textsatzsystem TeX wird als abgeschlosses
Projekt betrachtet. Die Versionsnummer konvergiert gegen Pi, das heißt immer
wenn irgendein Bugfix dazukommt, wird eine weitere Stelle von Pi an die
Versionsnummer herangehängt. Die derzeitige Versionsnummer ist 3.14159
Ebenso strebt das ebenfalls von Knuth entwickelte Programm METAFONT gegen die
Zahl e, die ebenso eine irrationale Zahl ist wie Pi. Derzeitige Versionsnummer
ist 2.7182.

haha, das ist wirklich witzig. Irgendwann haben sie dann Version 3.14159654... bzw.
2.718281828... - da steigt doch kein Mensch mehr durch ;o)

Gerüchteweise soll sich der MP3-Player Winamp für die großen Versionsnummern
bei der Fibonacci-Reihe bedienen. Dann aber nicht sehr konsequent; ich kann
mich jedenfalls nicht an zwei unterschiedliche Versionen 1 erinnern. Aber
man wird sehen, ob der nächste Player nach der Version 5 die Versionsnummer
8 tragen wird. ;o)

Die Version "5" von Winamp rührt ja auch daher, dass Winmap die Features des Winamp3 mit
denen des Winamp2 "gemixt" hat und daraus dann "Winamp2+Winamp3 = Winamp5!" gemacht hat.

"Winamp8" macht jetzt weniger Sinn, außer sie haben jetzt noch mehr Features von Winamp3
in Winamp5 gepackt *g*

Viele Grüße,

Sven

[MudGuard]

Hi,

haha, das ist wirklich witzig. Irgendwann haben sie dann Version 3.14159654... bzw.
2.718281828... - da steigt doch kein Mensch mehr durch ;o)

Wieso? Da reduziert sich doch die Frage nach der Versionsnummer auf die Länge der Zahl ;-)

cu,
Andreas

[MudGuard]

Hi,

Die Versionsnummer konvergiert gegen Pi, das heißt immer
wenn irgendein Bugfix dazukommt, wird eine weitere Stelle von Pi an die
Versionsnummer herangehängt.
Ebenso strebt das ebenfalls von Knuth entwickelte Programm METAFONT gegen die
Zahl e, die ebenso eine irrationale Zahl ist wie Pi.

Hm. Finde ich ungünstig, es sei denn man macht bei Nullen eine Ausnahme und hängt dann eben so viele Ziffern an, bis die letzte Stelle keine 0 ist.
Sonst führt das zu Verwirrung, weil Nullen am Ende des Nachkommateils gerne mal weggelassen werden ...

cu,
Andreas