Nachdem ich vorgestern einen Beitrag zum Thema Firefox-Entwicklung in diesem Jahr und der damit verbundenen Änderung des Veröffentlichungs-Rhythmus‘ geschrieben hatte, entbrannte eine Diskussion darüber, dass der Plan der Mozilla Foundation (auf deutsch gesagt) Mist sei. Es sei eine dumme Idee, so schnell neue Versionen zu veröffentlichen. Diese Grundaussage gab es nicht nur hier im Blog, sondern auch auf großen News-Seiten wie heise.de oder golem.de. Kaum jemand befürwortete die Entscheidung Mozillas. Der Plan wurde größtenteils als „Marketing-Gag“ dargestellt, „da höhere Versionen eine bessere Software suggerieren“.

Anzeige

Diese Aussagen entsprechen ganz und gar nicht meiner Meinung. Ich sehe kein Problem darin, die Veröffentlichungszyklen zu verkürzen. Die Vorteile der Entscheidung liegen für mich klar auf der Hand.

Vorteile kleiner Versionssprünge

  • Wenig Neuerungen, kalkulierbares Risiko: Es ist einfacher, wenige Neuerungen ordentlich zu testen und zu veröffentlichen, als viele Neuerung auf einmal. Die Änderungen werden bei jedem Release überschaubar und einfacher zu testen sein. Fehler sollten so im Endprodukt weniger vorkommen.
  • Funktionen, die früher beim Nutzer ankommen: Bereits gestern sprach ich den Punkt an, dass neu implementierte Funktionen mit kurzen Zyklen deutlich früher beim Endkunden ankommen werden. Firefox 3.6 ist zum Beispiel über ein Jahr alt. Seit Jänner 2010 wurde zwar viel am Browser gearbeitet, die Benutzer haben aber, mit Ausnahme der Sicherheitsaktualisierungen, nicht viel davon mitbekommen.
  • Die Entwicklung kann besser geplant werden: Es ist einfacher, die Entwicklung einer Software über ein paar Monate vorauszusehen, als über mehrere Jahre hinweg. Das führt dazu, dass Termine besser eingehalten werden können.
  • Schnellere Anpassungen an neue Marktverhältnisse: Nicht nur das Internet entwickelt sich mit der Zeit. Man kann die Entwicklung aber gerade beim Internet nur über kurze Zeit absehen. Wie dieses in 5 Jahren aussieht, kann keiner verlässlich voraussagen. Kürzere Release-Zyklen bieten bessere Möglichkeit um auf den sich wandelnden Markt reagieren zu können.

Major Release, Minor Release, Bug-fix Relase usw.

Viele haben sich darüber aufgeregt, dass eine Erhöhung der ersten Ziffer der Versionsnummer darauf hindeutet, dass größere Neuerungen in der Software zu finden sind bzw. großer Überarbeitungen stattgefunden haben. Dies mag bei vielen Programmen auch die gängige Praxis sein, am Ende ist aber jeder Programmierer bzw. jede Firme hinter einem Produkt selbst verantwortlich dafür, welche Versionsnummer eine Software bekommt. Das führt dazu, dass man sich rein auf Versionsnummern nicht verlassen kann.

Sehr sinnvoll halte ich eine Versionierung nach aufsteigenden Zahlen nicht. Sie bietet im Grunde nicht viele Informationen. Tatsächlich muss man sich sowieso Changelogs oder dergleichen ansehen, bevor man weiß, ob sich ein Upgrade lohnt. Und außerdem: Setzt irgendein Mensch auf der Erde eine Software ein, weil sie eine höhere Versionsnummer hat als die andere? Dem Brutto-Normal-Verbraucher ist die Software-Zahl sowieso egal. Dem ist es „wurscht“, ob da nach dem Firefox eine 4, eine 9 oder eine 4.000 steht. Es zählt einzig und allein die Leistung der Software.

Alternative Versionsbezeichungen

Viel sinnvoller finde ich da schon die Bezeichnung einer Software-Version nach Datum. Bei einem Windows 95 weiß jeder, dass die Software heutzutage veraltet ist, stellt man einem unwissenden Nutzer Windows XP vor, kann er sich wahrscheinlich wenig darunter vorstellen. Perfekt finde ich die Versionierung von Ubuntu. Ubuntu 11.04 bedeutet, dass die Software im April 2011 veröffentlicht wurde. Damit steht zwar noch nicht in der Versionsnummer, welche Neuerungen es gibt, allerdings kann man herausfinden, wie alt die Software ungefähr ist.

Außerdem scheint es mir in Zeiten von Online-Spielen, Online-E-Mail-Programmen und Co. sowieso so, dass Versionen heute eher eine untergeordnete Rolle spielen. Google hat auf seiner Suchseite auch nicht stehen, dass die Suchmaschine den bereits 1-Million-mal-überarbeiteten Algorithmus verwendet und trotzem – Google hat sich in den letzten Jahren immer weiterentwickelt – auch in kleinen Schritten. Ebenso läuft das mit anderen Seiten, wie Online-E-Mail-Programmen, so. Auch Facebook bringt praktisch monatlich Neuerungen heraus, eine Versionsnummer ist trotzdem nirgends zu finden.

Klar, bei Offline-Programmen werden Versionsnummern auch weiterhin erhalten bleiben. Irgendeinen Anhaltspunkt für Nutzer muss es ja geben, wo dieser sehen kann, ob die Version noch aktuell ist. Schließlich werden Offline-Programme im Gegensatz zu Online-Programmen auch nicht von selbst aktualisiert. Allerdings sollte es egal sein, welche Nummerierung ein Entwickler der eigenen Software wählt.

Verwendet Mozilla nun ein anderes Software-Modell, da damit die Entwicklung beschleunigt bzw. verbessert werden kann, soll es mir recht sein. Für mich zählt das Endprodukt und keinesfalls Versionsnummern.

Anzeige


10 Kommentare

  1. Ich finde Versionsnummern auf jeden Fall sinnvoll. So kann man ganz klar sagen welche Software z.B. miteinander sauber funktioniert.

  2. Das ist natürlich ein guter Grund für Versionsnummern. Allerdings ist es damit ziemlich egal, wie die Nummer genau aussieht.

    Gruß Valanin

  3. Sehe ich genauso. Ob Firefox jetzt in diesem Jahr FF5, FF6 und FF7 rausbringt oder FF11.04, FF11.08 und FF11.11 oder Firefox Hans, Firefox Erich und Firefox Joseph ist mir völlig schnuppe.

    Zugegeben, manche könnten sich von Versionssprüngen beeinflussen lassen. Aber wäre das ein Drama?

    Ich finde es gut, dass die Release Zyklen verkürzt werden und immer wieder kleine Änderungen in die neue Version einfließen. Wenn man immer 2 Jahre auf was neues warten muss ist das auch nicht so toll

  4. Stimme dir zu: Ubuntu hat schon eine recht sinnige Versionsnummerierung, nach Jahr und Monat. Machen aber einige andere Software-Projekte auch so oder änlich.
    Wie genau du auf den 4. April kommst weiß ich jetzt nicht, aber egal.

    Für Firefox könnte ich mir das auch vorstellen, immerhin ist es ja Egal wie mann es nennt, solange der Inhalt das ist, was man meint 😉 Der typische Nutzer wäre vielleicht ein Bisschen irritiert, aber das legt sich doch recht schnell, denke ich.

  5. Das mit dem 4. April war natürlich ein Fehler, wurde korrigiert. Danke!

  6. Hi!
    Zuerstmal: guter Beitrag. Sehe ich genauso. Versionsnummern sind nicht wirklich entscheidend. Ich finde es für Otto Normaluser sowieso verwirrend, wenn immer wieder neue Versionen rauskommen, dessen Versionsnummern sich an der 3. oder 4. Stelle hinterm Punkt verändern.

    Aber einen kleinen Fehler gibt es glaub ich in deinem Beitrag:
    Ubuntu 11.04 heißt nicht, dass es am 4. April rauskommt (der aktuelle Plan ist der 28.04. https://wiki.ubuntu.com/NattyReleaseSchedule) sondern einfach im 4. Monat des Jahres: April. 😉
    Allerdings muss ich dir zugute halten, dass Maverick am 10.10.2010 rauskam. Zufall glaub ich. =)
    liebe grüße

  7. ups, hab wohl zu lange fürs Tippen gebraucht 😀

  8. Ja, den Fehler hat schon ein anderer gefunden 😉

  9. Man kann auf Versionsnummern kaum Verzichten denn der Anwender muß von der Softwareversion Firefox X zu Firefox Y unterscheiden können.
    Dies lässt sich immernoch am besten mit der Zahlenfolge unserer Zählweise Darstellen.
    Selbst Google welche zwar mit Android Relasenamen eingeführt haben Verzichten nicht auf die zugehörigen Versionsnummern (android 2.3 gingerbread)
    Microsoft hatte es für Windows ebenfalls versucht Versionsnummern abzuschaffen, erst mit bezug auf Jahresangaben (95/ 98) dann mit Zusatz Namen, ist aber mit Win 7 wieder zur Versionsnummer Zählweise zurückgekehrt.

    Ich glaube aber das ab höheren zweistelligen oder gar deistelligen Nummern der Wiedererkennungs Effekt und die einprägsame Wirkung der Ziffern etwas nachlässt.

  10. Ich finde fortlaufende Versionsnummern unerlässlich aus schon erwähnten Gründen, meine aber, dass man sich an ein Schema halten sollte. Also: alle Softwareprojekte. Das allerdings ist schon deshalb nicht möglich, weil das Diktatur wäre und wir freiheitsliebende Menschen sind.

    Aber für den Fall dass hier zufällig ein Entwickler auf der Suche nach einem passenden Versionierungsschema vorbei schneit: Meine Idee wäre das Schema 1.2×3, zur Erläuterung folgendes.

    1) Major number / Generation: Unterschiedliche Ziffern signalisieren Inkompatibilität und die Notwendigkeit von Datenmigrationen.
    2) Minor number / Version: wird inkrementiert, wenn sich die Änderungen auf das sichtbare, äußere Verhalten des Programms auswirken.
    x) Entwicklungsstatus: a = alpha, b = beta, r = released, s = security update (of a deprecated version), u = unmaintained/unauthorised community fan-release
    3) Patch number: Fehlerkorrekturen und anderweitige Änderungen an der inneren Funktionsweise, während der Entwicklungsstatus gleich bleibt.

    Jede x.y-Version durchläuft die Stadien a, b, r und s, evtl. auch u. Die Patchnumber beginnt mit 1, nicht mit 0. Das erste veröffentlichte, neue Softwareprodukt trägt also die 1.0r1. 0.x-er Versionen signalisieren wie schon üblich, dass noch nicht alle geplanten Funktionsmerkmale realisiert sind, man also die Liste der geplanten Features studieren und Geduld üben / mithelfen sollte ehe man das Programm als völlig nutzlos verdammt. Der „x3“-Teil kann hier entfallen oder, falls Bedarf an zwei Versionierungsebenen besteht, auf „a“/“b“ reduziert sein.

    Das macht aus einer bloßen Versionsangabe einen Code, der jedem etwas bedeutet und noch dazu ungefähr das selbe.

    Wie gesagt Anregungen, so würde ich es machen, wenn ich ein Programm entwickeln täte. 😉

  11. Pingback: So langsam reicht’s: Genug Firefox-Versionsgeheule! | picomol.de

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert