Mozilla denkt über neues Release-Modell für Firefox nach
Nach der Veröffentlichung von Firefox 4 hat Mozilla ein neues Rapid Release Modell eingeführt, welches die Veröffentlichung neuer Firefox-Versionen alle sechs Wochen vorsieht, nachdem diese zuvor jeweils sechs Wochen als Nightly, Aurora und schließlich Beta entwickelt worden sind. Mozilla denkt nun über ein optimiertes Release-Modell nach.
Das Rapid Release-Modell hat der Entwicklung von Firefox nach anfänglichen Schwierigkeiten ohne jede Frage gut getan. Firefox hat sich in vielen Bereichen wieder zu einem Top-Browser entwickelt, Neuerungen werden schnell an den Mann respektive die Frau gebracht. Derzeit ist es so, dass neue Firefox-Versionen zunächst sechs Wochen lang als Nightly-Version in Entwicklung sind, ehe sie sechs Wochen als Aurora- und dann sechs Wochen als Betaversion reifen. Das entspricht einem 18-Wochen-Zyklus (3 x 6 Wochen) für die Entwicklung mit einer Lebenszeit von sechs Wochen pro Veröffentlichung. Auch der neue Vorschlag sieht einen 18-Wochen-Zyklus (2 x 9 Wochen) für die Entwicklung vor, bei welchem Aurora und Beta teilweise parallel laufen, die Lebenszeit finaler Firefox-Versionen erhöht sich dabei auf neun Wochen. Mozillas Manager des Release Management-Teams, Alex Keybl, nennt dieses Modell Coupled Train Model.
Hintergrund des Vorschlags ist, dass man seitens des Release Managements der Ansicht ist, dass die Aurora-Versionen keinen besonders guten Gebrauch der vollen sechs Wochen in jedem Entwicklungszyklus machen. Die meisten Probleme würden in der ersten Woche nach dem Merge behoben und auch die für die Betaphase kritischen Probleme werden innerhalb weniger Tage behoben. Die Qualität der Aurora-Versionen ist im Allgemeinen schon sehr hoch und neuer Code soll so schnell wie möglich an so viele Nutzer wie möglich gebracht werden. Daher möchte man neue Versionen stattdessen mehr als nur sechs Wochen in der Betaphase haben.
Das vorgeschlagene Modell sieht aber nicht einfach nur eine Verkürzung der Aurora- und Verlängerung der Betaphase vor. Stattdessen sollen diese teilweise sogar parallel mit derselben Versionsnummer laufen und neue Versionen nur noch alle neun Wochen veröffentlicht werden. Im Detail sieht das wie folgt aus:
Statt erst am Ende der Woche eines neues Major-Releases werden neue Aurora-Updates bereits am Tag nach der Veröffentlichung einer finalen Version aktiviert. Sobald kritische Probleme in den Aurora- und Release-Versionen behoben worden sind, Mozilla nennt hier einen Zeitraum von ein bis zwei Wochen, soll es bereits Betaversionen geben. Die Aurora-Versionen werden dabei allerdings parallel weiterlaufen und im Gegensatz zur Beta zusätzlich experimentelle Fixes erhalten beziehungsweise aktivierte Features, welche in der Beta-Version deaktiviert sind. Neun Wochen nach dem Merge von Nightly zu Aurora soll dann die finale Version erscheinen. Die Beta-Version behält noch ein bis zwei Wochen nach Veröffentlichung der finalen Version ihre Versionsnummer. Auf Grundlage dieser Betaversion können dann Patches für außerplanmäßige Updates in dieser Zeit getestet werden. Die für den Endanwender relevanteste Änderung des Ganzen wäre wohl, dass sich die Lebenszeit der finalen Versionen von sechs auf neun Wochen erhöht. Ein Vorteil für Entwickler bei diesem neuen Modell wäre, dass diese sich neben der jeweils aktuellen Version nur noch auf zwei künftige Versionen fokussieren müssen und nicht mehr auf drei.
[lightbox style=“modern“ image_path=“https://www.soeren-hentzschel.at/wp-content/uploads/coupled-train-model.png“ popup=“https://www.soeren-hentzschel.at/wp-content/uploads/coupled-train-model.png“ link_to_page=““ target=““ description=““ size=“two_col_small“]
Es sei an dieser Stelle noch einmal ausdrücklich darauf hingewiesen, dass es sich hierbei um einen Vorschlag handelt, der noch nicht in Stein gemeißelt ist. Davor gibt es noch verschiedene Dinge zu klären, beispielsweise wann in diesem Modell der String-Freeze für Übersetzungen oder der API-Freeze für Add-on-Entwickler ist, oder inwiefern Firefox OS davon betroffen wird. Auch ein Beginn für das neue Release-Modell steht noch nicht fest, der aktuelle Vorschlag geht von Firefox 30 aus.
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.
Interessante Idee, bedeutet aber auch im Umkehrsschluss, dass sich die Lebenszeit der ESR-Versionen um 7 mal 3, sprich 21 Wochen, verlängern würde. Das wäre vor allem für Thunderbird von Vorteil, weil der Community mehr Zeit für Verbesserungen bliebe, auf der anderen Seite würde es dann mehr als ein Jahr dauern, bis eine neue ESR-Version erscheint. Bisher dauert das 42 Wochen, dann würde es 63 Wochen dauern. Inwieweit ESR-Versionen dann noch Sinn machen, muss man schon hinterfragen, immerhin ist es schon diskussionswert, ob man im Unternehmen eher die modernen Features oder die mittelfristige Planungssicherheit braucht. Außerdem bleibt Addon-Entwicklern jetzt auch drei Woche mehr Zeit, Updates, falls nötig, für ihre Projekte zu veröffentlichen.
Wo ist da jetzt der Vorteil, wenn eine neuen Firefox-Version 3 Wochen länger als bisher dauert?
Features werden noch später veröffentlicht. Sehe da keinen Vorteil, dass weniger Final installiert wird und mehr Aurora Builds, da jetzt alles länger dauert.
Der einzige Vorteil ist, dass die Versionsnummer sich nicht mehr so schnell ändert.
klingt für mich dann nach einen Back-To-Basic 4er Firefox Konzept
@Antares:
Oder man reduziert die Anzahl der Versionen, welche einem ESR-Zyklus entsprechen. 😉 Aber richtig, der Punkt ESR-Version ist auch noch zu klären, davon wurde in dem Vorschlag noch nicht gesprochen.
ESR-Versionen ergeben für Unternehmen damit nach wie vor denselben Sinn würde ich sagen. Denn ob nun alle sechs oder alle neun Wochen eine neue Version veröffentlicht wird, für Unternehmen, die auf ESR angewiesen sind, bleibt das zu wenig.
@Steffen:
Den meisten Nutzern geht es doch sowieso zu schnell. Ich empfinde sechs Wochen als angenehm, aber ich weiß, dass das längst nicht jeder so sieht.
Naja, was heißt noch später? Sechs Wochen ist ein extrem strammer Zyklus und neun Wochen ist immer noch alles andere als langsam. Das sind zwei Monate statt 1 1/2 Monate. Wieso soll dadurch weniger Final installiert werden? Das verstehe ich nicht. An der Anzahl der Nutzer der finalen Versionen wird sich dadurch ganz sicher nichts ändern.
Das wiederum ist wirklich kein Vorteil. Das ist eine Zahl ohne tiefere Bedeutung. Mit einer neuen Veröffentlichung wird die Versionsnummer um 1 inkrementiert. Mehr als das bedeutet die Zahl nicht.
Eigentlich klingt es danach kein bisschen. Zum einen sind zwei Monate schon ein kleiner Unterschied im Vergleich zu 1 1/2 Jahren. Zum anderen gab es bei Firefox 4 und davor zu keinem Zeitpunkt ein Release-Modell, in welchem Alpha (was ich mal als Entsprechung für Aurora nenne) parallel zu Beta lief.
Klingt nicht unklug, was Sie vorhaben- hot security fixes vorher in einer mit der Releaseversion überlappenden Beta testen zu können, bzw. das selbe eben auch mit einer überlappenden Aurora u. Betaversion tun zu können ist für die Entwickler wohl definitiv ein Vorteil da hier Vergleiche an der Art wie sich der jeweilige State von Firefox bei dieser oder jener Änderung verhält gezogen werden können.
Letzten Endes würde es auf mehr Möglichkeiten des Testens und gegebenenfalls des Korrigierens hinauslaufen- im gesamten ergebe sich bei konsequenter Vorgehensweise eine bessere Gesamtübersicht für die Leute die den Fuchs programmieren bzw. weiterentwickeln.
Fazit: Kann ein Vorteil beim Feedback für die Entwickler u. damit auch für den Endverbraucher sein aber eben nur wenn man die dadurch erweiterten Vergleichs bzw. Testoptionen auch tatsächlich nutzt.
Schlau schlau- wau wau, habs ich richtig verstanden?