Wie ich noch aus eigener leidiger Erfahrung weiß und in der letzten Zeit auch bei einigen Linuxumsteigern miterleben darf, ist die Sache mit den Versionsnummern der verschiedenen Programme so eine Sache für sich.
Und um die schlechte Nachricht vorweg zu nehmen: Eine einheitliche Regelung gibt es nicht und somit auch keine einheitliche Lösung für das “Problem”.
Die gute Nachricht ist jedoch: Man muss sich nicht gleich zu Beginn mit den verschiedenen Arten Versionen zu zählen auskennen und in aller Regel reicht es auch, wenn man bei einer handvoll wichtiger Kernprogramme weiß, wie die Versionsnummern gezählt werden.
Zunächst sei einmal angemerkt, dass man sich über die Versionsnummern solange keine Gedanken machen muss, wie man nur die offiziellen, von der Distribution bei der Installation standardmäßig eingerichteten Repositories nutzt. Schließlich finden sich hier ausschließlich stabile Versionen die auf das Zusammenspiel mit der Distribution hinreichend getestet sind.
Allerdings bedeutet dies zumeist auch, dass man nicht gerade die aktuelste Version benutzt. Dafür ist es dann zumeist nötig, weitere Repositories einzubinden. Und hierbei ist es dann durchaus von gewisser Relevanz zu wissen, wie die Versionsnummern interpretiert werden.
Doch zuvor noch unbedingt der Tipp, einmal einen Blick in die Dokumentation der eigenen Distri zu schauen. Denn einige bieten Reprositories an, die neue und stablie Versionen enthalten und nutzen für instabile Versionen widerum andere Reprositories. Wenn dies der Fall ist, reicht es, einfach nur die richtigen einzubinden und man ist weitestgehend auf der sicheren Seite.
Ansonsten kann es jedoch nicht schaden wenn man die eine oder andere Art und Weise kennt, wie Versionsnummern gezählt werden.
Beispiel Firefox und KDE
Die Art und Weise, wie Firefox und KDE ihre Versionen nummerieren ist im Prinzip identisch. Die Versionsnummer ist dreistellig. Also bei KDE derzeit z.B. 4.5.0 Dabei gibt bei beiden die erste Ziffer den Majorrelease an. Also die jeweilige Hauptversion. Die zweite Ziffer kennzeichnet einen Minorrelease. Dies bedeutet, dass die Version nach wie vor, zu dem vorrangehend spezifizierten Majorzweig gehört, jedoch einige Änderungen und neue Funktionen mitbringt. Dabei sind diese Änderungen und neuen Funktionen jedoch nicht so umfänglich, dass es gerechtfertigt gewesen wäre, die Nummer für den Majorrelease um eins zu erhöhen.
Schließlich werden durch eine Änderung der dritten Ziffer die so genannte Bugfixreleases gekennzeichnet. Eine solche Version bringt in der Regel keinerlei neue Funktionen mit, behebt dafür aber einige Fehler und gegebenenfalls vorhandene Sicherheitslücken und sorgt somit dafür, dass die Anwendung stabiler läuft.
Dieses Verfahren Versiosnnummern zu zählen ist eigentlich sehr sinnvoll und auch entsprechend weit verbreitet, da man als Anwender hier auf einen Blick anhand der Versionsnummer sieht, mit was für einer Art von Release man es hier zu tun hat.
dies macht es jedoch nötig, Entwicklerversionen explizit als solche zu kennzeichnen. Allerdings ist ja auch das durchaus sinnvoll, z.B. ein Beta ausdrücklich mit in die Versionsnummer zu schreiben. Leider machen dies jedoch nicht alle. So kann es durchaus vorkommen, dass eine Versiosnummer wie 4.4.999 bedeuten soll,, dass es sich um die Entwicklerverion des bevorstehenden Release von 4.5.0 handelt. Ein wenig Vorsicht ist hier also geboten.
Kernel und Gimp: Die andere Art Versionsnummern zu zählen
Der Linuxkernel selbst, aber auch Gimp, haben eine andere Art ihre Versionen zu zählen, auch wenn auch hier die Versionsnummern nach dem Schema 2.6.8 dreigliedrig sind.
Auch hier gibt die erste Nummer den Majorrelease an. Die zweite Nummer jedoch hat nicht nur die Funktion, den Minorrelease zu kennzeichnen.
Vielmehr wird mit dieser Nummer angezeigt, ob es sich um eine instabile Entwicklerversion oder einen offiziellen Release für den produktiven Einsatz handelt.
Wenn die Ziffer gerade ist (also 2,4,6,8, etc für die mit geringer mathematischer Begabung;-) handelt es sich um einen stabilen Release. Bei einer ungeraden um eine Entwicklerversion.
Bei Gimp ist z.B. die Version 2.6.x die derzeit stabile Version. Bei den Versionen 2.7.x hingegen handelt es sich um die Entwicklerversionen für den kommenden Release 2.8
Die dritte Ziffer wiederum gibt bei Gimp Bugfixes an, beim Kernel hingegen eine neue Version. Schließlich kommt es hier eher selten dzu, dass die Nummer des Minorreleases um eins hochgezählt wird…
Abschließende Worte
Im Prinzip handelt es sich bei diesen beiden Arten Versionsnummern zu zählen um die, die am weitesten verbreitet sind und von denen man wirklich wissen sollte, wie die Nummern zu lesen sind.
Jedoch gibt es durchaus auch noch andere Arten um die Versionsnummern zu zählen und manche Projekte sind hier wirlich außerordentlich kreativ….
Insofern kann ich im Zweifel nur jedem empfehlen, auf der Hompage des jweilige Projektes nachzuschauen, wie das jeweilige Prijekt seine Versionsnummern zählt und wie diese zu interpretieren sind.
Fazit: Die nicht einheitliche Art der Versionsnummerierung unter Linux sorgt für ein gewisses Chaos, dass gerade den Einsteigern die Orientierung unnötig erschwert. Dennoch reicht es völlig aus, wenn man die beiden hier vorgestellten Arten der Versionsnumerierung kennt, da diese mit Abstand am weitesten verbreitet sind. Und im Zweifel halt immer auf der Homepage des Projektes nachschauen.
[...] http://bjoern-kraus.de/2010/06/24/linux-basics-versionsnummernchaos/ [...]