Rapid Release Process bei Firefox – ist das nun gut oder schlecht?
Mozilla hat mit dem sogenannten Rapid Release Process einen neuen Release-Zyklus für neue Firefox-Versionen eingeführt (auf dessen Zug übrigens auch der Mail-Client Thunderbird sowie die Browser-Suite SeaMonkey aufgestiegen sind). Grob zusammengefasst sieht dieser alle sechs Wochen die Veröffentlichung einer neuen Browser-Version vor. In Zusammenhang hiermit stoße ich in diversen Diskussionen immer wieder auf Kritik an diesem neuen Modell. Die größte Reibung entsteht hierbei beim Hochschnellen der Versionsnummer, auch um die Kompatiblität von Addons ist man besorgt. Außerdem in den Top 3: Reine Bequemlichkeit, den Browser zu updaten. In diesem Artikel möchte ich erklären, wieso ich diese Kritik für einen großen Teil für nicht angebracht halte und welche Vorteile der Rapid Release Process für den Endanwender aus meiner Sicht wirklich bringt.
Das Web entwickelt sich sehr schnell, gerade deswegen ist es sehr wichtig, Änderungen auch entsprechend schnell an den Mann respektive die Frau zu bringen. In der Vergangenheit hat es durchaus mal seine 12 Monate oder mehr gedauert, bis Mozilla eine neue Version von Firefox (Sicherheitsupdates sind in diesem Kontext nicht relevant) veröffentlicht hat. Das ist deutlich zu lange und durfte so in keinem Fall weitergehen. Mozilla hat es sich auf die Fahne geschrieben, das Web zu verbessern und vor Hintergrund dieser Mission ist es nicht förderlich, Entwicklungen zurückzuhalten, nur weil man sich für jeden Major Release vornimmt, den Browser an wirklich jeder Stelle aufzubohren. Man hat auch einiges an Marktanteilen dadurch verloren, dass die Konkurrenzbrowser mächtig Boden gut gemacht haben, weil sie einfach schneller besser wurden, während Mozilla sich selbst zu hohe Ziele gesteckt hat.
Nicht wenige Leute schimpfen nun darauf, dass es doch nur darum ginge, Chrome nachzueifern und die Versionsnummer hochzujagen. Ich möchte nicht leugnen, dass dieser küchenpsychologische Aspekt durchaus existieren mag, dass eine hohe Versionsnummer einen besseren Browser suggeriert. Diesen Anteil halte ich allerdings nicht für übermäßig hoch. Viel mehr bin ich der Meinung, dass man sich einfach mal von der alten Versionierung freimachen muss. Eine Inkrementierung der Versionszahl bedeutet nun eben einfach nicht mehr, dass Firefox wieder ein bahnbrechend neues Erlebnis bietet, sondern der nächste Meilenstein bei der Entwicklung eines sehr guten Browsers erreicht wurde. Der Mensch ist eben ein Gewohnheitstier und mag keine Veränderungen von „altbewährten“ Dingen, auch bei solchen vermeintlichen Kleinigkeiten. Ich sehe es so: Die Versionsnummer ist nicht mehr als ein Nebenprodukt, welches einem einen Überblick darüber gibt, wo man gerade steht. Nicht weniger, aber auch nicht mehr. Und wieso sollte Mozilla nicht auch das machen dürfen, was Google macht?
Es wird sich darüber aufgeregt, dass man nun so den Browser häufiger updaten müsste – ganz ehrlich, alle 1 1/2 Monate ein kurzes und schmerzloses Update, wem tut das jetzt weh? So viel mehr ist das nämlich überhaupt gar nicht. Nehmen wir es sogar ganz genau sind es weniger (!) Updates als vorher. Denn es gibt keine fünfzehn Minor-Updates pro Major-Release mehr. Vielleicht noch einen, vielleicht auch zwei, vielleicht sogar gar keinen. Bei Firefox 3.6.x sind wir bei der 18. Revision (3.6.17) angekommen, Firefox 4 ist erst bei 4.0.1 und viel mehr wird es wohl auch nicht geben. Weil nicht notwendig.
Fairerweise muss man sagen, dass die „Update-Phobie“ nicht ausschließlich in der Bequemlichkeit liegt, sondern Sorge um die Kompatibilität von Addons eine nicht geringe Rolle spielt. Doch auch hier muss man nur einmal kurz nachdenken: Kürzere Release-Zyklen bedeuten doch unausweichlich deutlich weniger Änderungen an den APIs, auf welche die Erweiterungen zugreifen. Als Entwickler von Erweiterungen kann ich sagen, dass die Änderungen von Release zu Release extrem umfangreich waren und die Veröffentlichung einer neuen Version viel Arbeit machen konnte, was so manch einen mit Sicherheit überfordert hat. Mich hat es das in jedem Fall, gebe ich ganz offen zu. Das wird in diesem Ausmaß so nicht mehr zu erwarten sein, jetzt gibt es von Release zu Release weniger anzupassen, da kommt man als Erweiterungsautor wesentlich besser mit. Dazu kommt, dass alle Erweiterungen, die auf der offiziellen Erweiterungsplattform von Mozilla gehostet werden, automatisch darauf überprüft werden, ob sie von den API-Änderungen betroffen sind und wenn nicht in der Kompatiblität automatisch in der Versionsnummer nach oben gesetzt werden. Anderenfalls wird der Entwickler per E-Mail über die betroffenen Teile der Erweiterung informiert. Das erspart den Entwicklern diese nervige Einstellarbeit mit jedem Release. Zwar werden die Erweiterungen nicht bereits für die aktuellste Nightly-Version überprüft, aber da es hier für die Kompatibilitätsüberprüfung nur noch einen Schalter für alle Versionen gibt, entfällt auch hier wieder Arbeit für den Anwender. Also auch in der Sache Addons bietet das neue Modell viele Vorteile. Natürlich bleiben immer ein paar Erweiterungen auf der Strecke, das ist bei allem so. Aber die ganz große Masse ist mit bzw. spätestens kurz nach Release mit Sicherheit kompatibel. Und Erweiterungen, die mit dem mit Firefox 4 eingeführten Addons SDK erstellt wurden, benötigen eh keinerlei Anpassungen, deren Kompatibilität ist garantiert.
Aber der genau gleiche Aspekt tritt ja nicht nur bei den Erweiterungen auf. Ich bin schon sehr vielen „konservativen“ Firefox-Benutzern begegnet. Die Änderungen von Version zu Version waren so umfangreich, dass sie sich gesagt haben, dass sie gar nicht erst auf die neuste Version umsteigen wollen. Auf das ganze „Gefrickel“, wieder alles den eigenen Vorstellungen entsprechend anzupassen hätten sie keine Lust. Und parallel zu den Erweiterungen können wir hier wieder sagen: Es ist nicht mehr so viel, man kann relativ beruhigt den Browser aktualisieren und statt mit einem mal den halben Browser anders zu haben, wird man hier nun schrittweise hingeführt.
Was bleibt nun also wirklich schlechtes an diesem Modell? Der größte Nachteil ist wohl, dass nun deutlich weniger neu ist von Version zu Version als bisher der Fall. Aber wie wir eben festgestellt haben, liegt genau hierin auch der Ursprung für einige, nicht unbedeutende Vorteile. Einzig kritisieren würde ich, dass die Entwicklung praktisch nur noch in der Nightly-Version stattfindet und bereits in der Aurora-Phase kaum noch etwas passiert. Ich würde mir eine längere Nightly-Phase und dafür ein kürzeres Aurora- / Beta-Intervall wünschen. Denn das Auge isst nun einmal mit und der Endanwender will viel Neues sehen.
Alle Informationen zum kommenden Firefox 5 (Release: 21. Juni) gibt es hier, was sich mit Firefox 6 ändern wird, könnt ihr hier nachlesen.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Im Prinzip hast du recht, aber bis dieses neue Verfahren (weniger Änderungen pro kleinerer, schnellerer Version + schnell wachsende Versionsnummer im Vgl. zur sehr konservativem Zählung bei Mozilla bisher) auch beim letzten Mozilla-Nutzer angekommen ist und verstanden und akzeptiert wurde, wird noch eine Menge Zeit vergehen und viele kritische Stimmen wird es geben.
Aber wie bei jeder Anpassung an neue Gegebenheiten, die von außen „aufgezwungen“ werden, wird man danach wahrscheinlich stärker hervorgehen als man vorher war. Bei der derzeitigen relativen Stagnation braucht Mozilla das eh.
Ich stimme dir voll zu – nur es ist alle 6 Wochen und nicht alle 18 Wochen 😉
Hui. Da steckt ja ein ziemlich tiefer Logikfehler bei mir drin, der mir jetzt erst bewusst wird. Ich bedanke mich für den Hinweis! Werd ich mal gleich korrigieren!
„Das Web entwickelt sich sehr schnell, gerade deswegen ist es sehr wichtig, Änderungen auch entsprechend schnell an den Mann respektive die Frau zu bringen.“
Das würde ich nur teilweise so unterschreiben, denn damit Webseiten Technologien einsetzen können, müssen sie entweder von allen Browsern unterstützt werden oder Browserweichen programmiert werden, welche den nicht-unterstützten Browser trotzdem den Inhalt zugänglich machen.
„Man hat auch einiges an Marktanteilen dadurch verloren, dass die Konkurrenzbrowser mächtig Boden gut gemacht haben, weil sie einfach schneller besser wurden, während Mozilla sich selbst zu hohe Ziele gesteckt hat.“
Das geschah nicht wegen mangelnder Unterstützung neuester Webtechnologien (bei Add-ons ist die Unterstützung der Konkurrenz derzeit eh begrenzter), sondern wegen der Wahrnehmung des Ressourcenverbrauchs. Selbst beim Mozilla Summit vor einem Jahr sagte jemand in der oberen Hierarchie von Mozilla, dass er den Druck von außen spürt für die Performance etwas (also nicht selbst wahrnimmt). Mit dem Ziel des reduzierten RAM-Bedarfs („MemShrink“) wird jetzt auch daran gearbeitet und Firefox sollte wieder besser reagieren. So lange solche Änderungen nicht APIs entfernen oder deren Funktionen verändern, kann man sie auch in einem kleinen Update veröffentlichen.
addons.mozilla.org (AMO) versucht die Erweiterungskompatibilitäten hochzusetzen, wenn nach der Analyse der Erweiterung nichts darauf hindeutet, dass sie von einer Änderung betroffen wäre. Aber viele verteilte Arbeitsvorgänge kosten (IMHO) mehr Zeit als wenn man alles in einem Ritt machen kann (zumindest in Teile von Quellcodes muss ich mich stets einarbeiten). Und das Add-ons SDK garantiert nicht Kompatibilität, man hofft, die APIs lange stabil halten zu können.
Huhu,
natürlich ist es absolut notwendig, dass die Technologien relativ flächendeckend unterstützt werden, damit sie überhaupt eingesetzt werden. Aber die Entwicklungen gibt es, also gibt es auch keinen Grund, diese zurückzuhalten. Es ist ja nun nicht Mozillas Ziel, ausschließlich Dinge umzusetzen, die die Konkurrenz bereits umgesetzt hat. Mozillas Anspruch muss es sein und ist es auch, Vorreiter zu sein. Ansonsten darf man sich auch nicht wundern, wenn die Marktanteile sinken, weil eben Chrome und Opera schneller die Neuerungen bringen und auch der IE langsam aber sicher den Anschluss findet, weil man nun Dinge umsetzt, die andere schon lange können. Da reicht es nicht aus zu warten, bis alle anderen es haben. Mozillas Position ist stark genug möchte ich behaupten, um Entwicklungen voranzutreiben. Zusammen mit meinetwegen Google. Sie haben meiner Meinung nach eine gewisse Verantwortung, die sie sich selbst auferlegt haben. Und damit setzen sie auch die Konkurrenz aus Redmond wiederum unter Druck, was ganz in ihrem Sinne sein dürfte. Was die Thematik Marktanteile betrifft ist es ganz klar, dass da viele Faktoren reinspielen. Ich habe nur einen Teil genannt, aber mit dem meine ich auch nicht ausschließlich Webstandards, sondern eben auch Dinge wie RAM-Verbrauch und Performance. Hier ist die Konkurrenz mächtig vorbeigezogen. Mit Firefox 4 konnte man zwar wieder in die Nähe gelangen, aber wenn man weiter daran festhält, alle 12 Monate oder gar weniger einen neuen Release zu bringen, wird man performancetechnisch auch dauerhaft hintenbleiben und langsam aber sicher den Anschluss verlieren. Mozilla kann es sich nicht leisten, wenn sie ihre User behalten wollen, dass sie jedes Jahr performancetechnisch zwar einen großen Schritt machen, auf dem Weg aber bereits viele Anhänger verlieren, weil in dieser Zeit der Abstand wieder spürbar wächst. Ich kann natürlich nicht sagen, was in den Köpfen der Führungsetage vor sich geht, der ganze Artikel spiegelt wie dort auch gesagt meine persönliche Meinung wieder. Und ich mache eben meine eigenen Beobachtungen, was Anwender sagen und da ist das für mich die klare Folgerung, dass das User kostet, wenn man so weitermacht wie bisher. Zur Addon-Kompatiblität noch: Eine dauerhafte Kompatiblität bis in alle Ewigkeiten kann natürlich bei nichts garantiert werden, aber eben über einen bestimmten Zyklus. Erweiterung mit dem SDK in Version 1.0 sind bis mind. Zeitpunkt x kompatibel, Version 1.1 bis mind. Zeitpunkt y. Niemand kann erwarten, dass 2012 noch kompatibel ist, was 2010 erstellt wurde. Da hatte ich kürzlich eine schöne Grafik zu, die hat das gut veranschaulicht, aber die hab ich gerade nicht zur Hand, deswegen kann ich das auch nicht mehr im Detail wiedergeben, wie die Planungen diesbezüglich aussehen.
Ich verstehe nicht ganz, wieso man nicht alle sechs Wochen statt einer neuen Haupt- eine neue Nebenversion rausbringt. Dadurch hätte man rapid release, würde das Standardversionierungsschema aber nicht durchbrechen, oder täusche ich mich da?
Im Prinzip stimmt das schon. Nur wäre dann wohl die Frage: Was ist nun Firefox 5, 6, 7? Schließlich ist das ein festes Modell, jeder Release geht seine 18 Wochen, davon sechs Wochen aktive Entwicklung, durch, so gesehen ist jeder Release gleichwertig. Je nachdem, welche Projekte dann bis zum Aurora-Merge soweit sind, dass sie einfließen können, bzw. wie umfangreich diese sind, kann es natürlich schon sein, dass sich der Umfang der Änderungen mal mehr und mal weniger bemerkbar macht, was ein Kriterium wäre. Nur stelle ich mir die Versionierung dann ziemlich schwierig vor, wenn – wie es ja ist – drei Versionen parallel entwickelt werden mit teilweise täglichen Updates und man möglicherweise erst kurz vor knapp feststellen kann, was es nun noch geschafft hat und was auf den nächsten Release verschoben wird. Dann ändert sich ja der Umfang des Releases und man kann dann ja nicht einfach die Versionsnummer entsprechend anpassen, weil das ganz sicher Probleme mit dem Building, den Updates etc. nach sich ziehen würde. Letzteres ist jetzt rein spekulativ von mir, aber ich könnte mir gut vorstellen, dass das problematisch sein kann. Und es ist so auch das Einfachste. Jeder Release Versionsnummer + 1, es ist zumindest ein nachvollziehbares Schema, welches keine weiteren Entscheidungen oder gar Diskussionen mit jedem Release fordert.
„So lange solche Änderungen nicht APIs entfernen oder deren Funktionen verändern, kann man sie auch in einem kleinen Update veröffentlichen.“
Wir haben derzeit sehr wirksame Patches genau in diesem Segment – RAM-Verbrauch zu reduzieren – die sogar für Aurora möglicherweise zu aggressiv sind und daher ev. auf FF7 warten müssen, weil sie zu weit in den Kern-Code greifen, um in der Stabilisierungsphase von FF6 noch reingeschoben zu werden. In einer „stabiklen“ Serie wäre das ganz unmöglich, sowas auszuliefern.
Das kann ich teilweise nachvollziehen. Dennoch ist es für mich persönlich wichtig zu wissen, wieviel sich seit dem letzten Release geändert hat. Und das kann ich jetzt nicht mehr eben so sehen.
Was passiert eigentlich, wenn bei einer umfangreichen Überarbeitung von Firefox die nächste Version nach sechs Wochen noch nicht fertig ist?
Was sich geändert hat, sollte ab dem Aurora-Stadium schon vorläufig feststehen, ab Beta dann ziemlich final, und sollte in Release Notes ersichtlich sein, so wie immer.
Was passiert, wenn etwas nicht fertig ist, das ist einfach, es kommt sechs Wochen später. Einzelne neue Funktionen werden deaktiviert, wenn sie in Aurora oder gar Beta nicht reif genug für die Massen sind. Sollte mal gegen Ende des Beta-Zyklus das ganze Produkt nicht der Qualität entsprechen, die wir von einem Release verlangen, wird das ganze Release um sechs Wochen verschoben.
Zunächst mal vielen Dank an euch für die Infos, das ist für mich alles sehr interessant.
Aber Du denkst doch nicht wirklich, dass sich Endbenutzer die Release Notes ansehen, oder? Die sehen bloß, dass eine neue (Haupt-)Version rausgekommen ist. Und, ganz ehrlich, ich hab auch keine Lust, die Release Notes durchzulesen. Dafür würde (fast) jeder nachvollziehen können, dass ein Schritt von 4 auf 5 mehr ist als einer von 4.0 auf 4.1.
Und was ist, wenn nach sechs Wochen noch kaum etwas fertig ist (einfach mal angenommen)? Dann lohnt sich ja ein Release nicht.
Für den Endbenutzer ist ein automatisches Update ein automatisches Update, er/sie kümmert sich nicht darum, ob es „nur“ Schicherheitsupdates sind oder manche kleine Funktionsänderungen beinhaltet. Das hat zum Beispiel auch 3.6.4 bewiesen, wo wir eine größere Funktionsänderung (Plugins in eigenen Prozessen) in einem „Sicherheitsupdate“ ausgeliefert haben.