Mozilla ändert Release-Zyklus von Firefox
Mehr als vier Jahre nach Einführung des Rapid-Release-Modells führt Mozilla eine Anpassung des Release-Zyklus von Firefox durch und ersetzt den bisherigen 6-Wochen-Zyklus durch einen variableren Zyklus.
Seit der Einführung des Rapid-Release-Modells, welcher Firefox nun schon mehrere Jahre begleitet, wird alle sechs Wochen ein neues Feature-Update von Firefox veröffentlicht, einzelne Verschiebungen ausgenommen. Nun hat Mozilla neue Release-Termine für 2016 bekannt gegeben, welche einen variableren Zyklus zeigen. Demnach werden neue Firefox-Versionen nicht mehr fix alle sechs Wochen veröffentlicht, sondern alle sechs bis acht Wochen. Außerdem wird im Dezember anstelle eines Feature-Updates lediglich ein Bugfix-Release mit Änderung der Versionsnummer an dritter Stelle erscheinen.
Die neuen Release-Termine Firefox 2016
8. März 2016 / 6 Wochen nach Firefox 44
Firefox 45, Firefox ESR 45
19. April 2016 / 6 Wochen nach Firefox 45
Firefox 46
7. Juni 2016 / 7 Wochen nach Firefox 46 (6 Wochen durch Verschiebung von Firefox 46)
Firefox 47
2. August 2016 / 8 Wochen nach Firefox 47
Firefox 48
13. September 2016 / 6 Wochen nach Firefox 48
Firefox 49
8. November 2016 / 8 Wochen nach Firefox 49 (7 Wochen durch Verschiebung von Firefox 49)
Firefox 50
13. Dezember 2016 / 6 Wochen nach Firefox 50, nur Bugfixes
Firefox 50.0.1
24. Januar 2017 / 6 Wochen nach Firefox 50.0.1
Firefox 51
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, mozilla.de, firefoxosdevices.org sowie sozone.de.
Der Zyklus sieht, ich sag mal, ungezwungener aus. 🙂
Bestimmt aber wird es für viele immer noch viele Wochen zu kurz sein. ;p
Ein Releasezyklus wie bei Mesa3D wäre schön :p
Ich habe nichts gegen schnelle Releases, auch damals bei Einführung schon nicht. Aber ich habe auch damals schon gesagt, dass auf Dauer eine starrer Plan einfach nicht gut gehen wird.
Man sollte einfach nicht nach Datum veröffentlichen. Sondern sich kleine(!) Feature-Ziele setzen und veröffentlichen sobald diese implementiert sind. „It’s done when it’s done“ in kleinen Häppchen. Dann dauert es halt mal 4, mal 8 Wochen. Who cares?
Ist es nicht bald sinnvoller, die Zählweise der Versionsnummern etwas abzuändern? Ubuntu hat bspw. mit YY.MM ein ziemlich logisches System gefunden. Danach würde Firefox 51 lediglich Firefox 17.01 oder 2017.01 (um dem Millenium-Bug vorzubeugen) heißen. Spätestens bei Firefox 100 in 7 Jahren müssten die meisten den Überblick verlieren. 😉
@Sven:
Also alle drei Monate und dazwischen viele kleine Updates?
Das hat sich bis heute aber nicht bewahrheitet, dass es nicht gut gehen würde, der Release-Zyklus ging und geht wunderbar. Es wird nun lediglich mehr Flexibilität hinein gebracht, aber der Zyklus bleibt weitestgehend gleich. Dass es jetzt mal eine oder zwei Wochen mehr gibt, ist ja keine grundlegende Änderung, die alles verändert. Ein starrer Plan wie vorher ist sicher nicht optimal, nur "nicht gut gehen" klingt, als hätte es ernsthafte Probleme gegeben. 😉
Nein, dieses Modell gab es früher und war wirklich nicht gut. „It’s done when it’s done“ gilt so oder so, auch in diesem Modell. Es gibt kein Feature, welches unbedingt in eine bestimmte Version muss. Jedes Feature kommt dann, wenn es fertig ist. Dieses Release-Modell hat noch nie verschuldet, dass ein Feature halb fertig ausgeliefert wird. Mozilla kann wunderbar kontrollieren, dass Features hinter Einstellungen entwickelt werden und/oder nur in bestimmten Release-Kanälen an die Nutzer ausgeliefert werden.
Dein Vorschlag, es so wie früher zu machen, trägt nur dazu bei, dass die Termine vollkommen unvorhersehbar sind, und das wäre überhaupt nicht gut, das schafft ganz eigene Probleme, die mit diesem Modell vermeidbar sind.
Das ist nicht sinnvoller, weil das derzeitige Versionierungssystem einen klaren Sinn hat. Änderung an erster Versionsstelle = Major-Release, Änderung an zweiter Versionsstelle = ESR-Update, Änderung an dritter Versionsstelle = Bugfixes und Sicherheitsupdates. Von diesem Aspekt her ist die Versionierung von Ubuntu – für Firefox – überhaupt nicht gut, denn das lässt sich damit so nicht abbilden. Für Ubuntu mag das passen, ich sag nicht, dass das generell schlecht sei. Aber die Anforderungen sind einfach andere bei Ubuntu und bei Firefox.
Ich wüsste jetzt nicht, wieso man spätestens bei Firefox 100 den Überblick verlieren müsste. Im Prinzip gibt es doch nichts Übersichtlicheres als ein klares Nummernsystem, welches immer um eins inkrementiert wird. Das ist die einfachste Form der Versionierung und das System, welches man von so ziemlich jedem Produkt kennt. Es sind Ausnahmen, die es anders machen.
Und letztlich ist es ja vollkommen egal, wie eine Version heißt, es ändert nichts am Produkt. Daher ist alles prima, wenn mit der Versionierung das ausgesagt werden kann, was ausgesagt werden soll. 😉
MediaWiki (die Software mit der Wikipedia betrieben wird) ist ein Beispiel dafür, dass man sogar mit noch kürzeren Release-Zyklen produktiv arbeiten kann, die MediaWiki-Version, die für Wikipedia verwendet wird, wird (von ein paar Ausnahmen abgesehen) nach einem festen Plan jede Woche aktualisiert.
Das Ubuntu-Versionsschema ließe sich durchaus auch für Firefox sinnvoll einsetzen, eben als Ersatz für die erste Versionsstelle. während die weiteren Stellen weiterhin so behandelt würden, wie sie jetzt verwendet werden.
Zumindest ist es ziemlich wahrscheinlich, dass zu dem Zeitpunkt ein paar Seiten, die den Useragent-String auswerten, damit auf die Nase fallen. (Wobei man sagen muss: Wer das überhaupt tut, ist schon selber schuld.) Bei Opera hat man nicht ohne Grund ab der Version 10 die Versionsnummer etwas versteckt und sich weiterhin für Version 9.80 ausgegeben.
Das lässt sich natürlich in der Tat nicht ausschließen. Es gibt in der weiten Internet-Welt wirklich furchtbare Implementierungen von User-Agent-Sniffing. 🙁
Ich finde eine Versionsnummer aus Jahr.Monat am Besten. Da weiß man als Kunde viel besser wie aktuell die Version ist.
Vor allem bei regelmäßigen und automatischen Updates sind Versionsnummern für den Kunden/Konsumenten doch vollkommen egal. Da will man höchstens mal schauen ob die Version neu ist und das geht am Einfachsten über das Datum.
Um zu sehen, ob die Version aktuell ist, ist die Versionsnummer ja egal. Man ruft den Infodialog auf und dann wird automatisch überprüft, ob es eine neue Version gibt. Und wie gesagt ist Jahr und Monat nicht ausreichend. Du musst sowohl Bugfix- als auch ESR-Releases darstellen, du bräuchtest also wenigstens vier Stellen. Und ich bezweifle, dass die Mehrheit wüsste, was diese Versionsnummer darstellen sollen. Ein Datum lässt sich so nicht mehr ablesen, wenn man es nicht weiß, dass es ein Datum sein soll. Und Nummern, die immer um 1 erhöht werden, sind ein Schema, welches jeder Nutzer kennt und einfach vertraut ist. Klassischer geht es nicht. Das hat sich nicht grundlos durchgesetzt.
Dem kann ich zustimmen. Aus Endnutzersicht ist es, wenn man sich über eine Version informieren möchte, schöner und eleganter, wenn man erkennt, aus welchem Jahr das Release stammt.
Aus Entwicklersicht wird meinen Informationen nach doch eh mit Mercurial gearbeitet, Versionen kann man da mit Tags markieren.
Siehe Antwort auf diesen Kommentar, Jahr plus Monat kann nicht ausreichend sein.
Versionsnummern werden nicht nur intern verwendet, sondern auch für sämtliche Kommunikation nach außen.
Ich fand die 6 Wochen Zyklen super, kann aber auch ganz gut mit max. 8 Wochen leben. Solange es nicht so lange dauert wie früher ist alles bestens.
Ob eine, zwei, drei oder vier Stellen ist vollkommen egal. Das, was bei einem Programm im „Über“-Dialog steht, ist lediglich eine Darstellung(!) einer Zahl.
Das Textsatzsystem TeX hat als Versionsummer eine Näherung der Zahl Pi. Mit jedem neuen Release nähert man sich etwas näher an. Momentan ist man bei „3.14159265“. Das ist EINE Zahl (ein Float), die hochgezählt wird.
Man kann auch bei x.y.z die Punkte einfach weglassen und entweder +1, + 10 oder +100 machen.
Die Datumsvariante „2015.10“ kann man in einen Timestamp umrechnen.
JEDE Versionsummer lässt sich auf EINE Zahl zurückführen und diese Darstellung quais beliebig in jede andere Darstellung transformieren. Die Bits des Timestamp könnte man beispielsweise in gleichgroße Blöcke aufteilen und Punkte dazwischen machen. Dann hätte man auch irgendwas wie Version „30.44.23“. (Randnotiz: genauso funktionieren IPv4-Addressen, das sind auch einfach nur 32 Bit, die nur der schöneren Darstellung/Lesbarkeit wegen in kleine Blöcke geteilt werden).
Genauso kann ich eine Liste definieren 1=Monsun, 2=Sören, 3=Foobar, 4=Automat, … und bei jedem neuen Release (egal ob „Bugfix“ oder „Major“) das entsprechende Wort nehmen. Die Zahl könne ich aber genausogut in ihre Bits zerlegen udn ein 0.0.1 oder 0.3 oder 3.0 draus machen, jenachdem wo ich die Punkte hinsetze.
Dieses Versionsrennen finde ich nicht wirklich übersichtlich, eher Chaotisch.
Zwei bis drei Versionen pro Jahr sollten doch eigentlich reichen, immer dann vielleicht, wenn eine grundlegende, bedeutende technische Änderung oder ein bedeutendes Feature hinzugekommen ist. Meilensteine eben. Kleine Features sollten eher Bugfixes sollten eher nach den Punkt kommen (oder Bugfixreleases generell mit Buchstaben wie z.B. 48.2.a?).
Ich finde dieses sture hochzählen eher chaotisch bis unbeholfen.
Um mal wieder zum eigentlichen Thema, dem Release-Zyklus von Firefox, zurückzukommen:
Was exakt war denn nun ein Nachteil des vorhersehbaren 6-Wochen-Rhythmus?
Was ist besser an „6 6 7 8 6 8 6 6“ Wochen?
Das sind im Durchschnitt nun 46 Tage anstatt wie bisher 42 Tage. Wozu diese minimalen Variationen?
Müssen sich die Nutzer nun nach den Urlaubszeiten der Mozilla-Angestellten richten?!
Oder wie kommt diese holprige Zahlenfolge zustande?
Ich kann leider keinerlei Regel darin erkennen. Bitte, klärt mich auf!
Ich wette mal dass Version 48 oder 50 e10s für alle eingeschaltet werden wird. Die 8-wöchige Betaphase würde zumindest etwas mehr Zeit zum testen geben. Zumindest gehe ich davon aus dass es schon Pläne gibt.
Vorallem die letzten beiden Releases sind sehr interessant. Sollte es sich bei 50.0.1 um ein Bugfix Release handeln hat v51 sogar 12 Wochen Entwicklungszeit. Wurde schon angekündigt ob da irgendetwas "besonderes" released wird?
Naja was die Versionsnummer betrifft: Ich hab keinen Dunst welche Version aktuell ist, nach Firefox 17 hab ich aufgehört zu zählen.. Womöglich könnte man sich die Versionsnummern einfach schenken, denn wie du bereits sagtest, man kann es nicht an der Softwareweiterentwicklung festmachen wie der Versionszähler inkrementiert wird. Momentan sind es ja einfach nur die Anzahl der 6 Wochenzyklen die seit mitte/ende 2010 vergangen sind ^^
@foobar:
Alles richtig. Aber bedenke, dass Versionsnummern auch dafür da sind, um über eine bestimmte Version kommunizieren zu können. Das ist leichte Verständlichkeit Trumpf. 😉
@Markus:
Diese Folgerung ergibt ja nun nicht wirklich viel Sinn. Wie kann ein ganz klarer Plan auf dich chaotisch oder unbeholfen wirken, wo doch das Gegenteil offensichtlich ist? Erkläre das bitte.
Nein. Es bringen nicht sowohl Mozilla als auch Google so häufig neue Versionen heraus, weil nichts dafür sprechen würde, das Gegenteil ist auch hier zutreffend. Gerade, weil Google das macht, kann Mozilla es sich nicht leisten, nicht mitzuziehen. Außer, sie wollen noch mehr Nutzer verlieren, weil Firefox immer wieder an Boden verliert.
Es gibt in ausnahmslos jedem Major-Release nennenswerte Neuerungen.
Ein hinten angestelltes A in der Versionsnummer steht üblicherweise für eine Alpha-Version. Und wenn du Updates für kleinere Features willst, müsste es alle zwei Wochen neue Updates geben, nicht mehr nur zwei bis drei mal im Jahr, wie du es gerade noch wolltest. Damit widersprichst du deinem eigenen Standpunkt.
@Manu:
Es geht nicht darum, dass die Anzahl der Wochen unterschiedlich ist, es geht um die konkreten Zeitpunkte, welche besser oder weniger gut geeignet sind. Aufgrund jahrelanger Erfahrungen weiß man beispielsweise, dass im Dezember Weihnachten und Neujahr ist, wie Mitarbeiter Urlaub haben, wann Workweeks geplant sind etc. Man reagiert ganz einfach flexibler auf die Realität.
Selbstverständlich müssen sie das unter Umständen, ohne Mozilla-Angestellte gibt es schließlich keinen Firefox-Release. Ich verstehe die Frage nicht wirklich.
Ganz einfach, weil es keine Regel dahinter gibt. Jeder Termin ist individuell ausgewählt.
@Marcel:
Die Prognose Firefox 48-50 mag hinkommen, es gibt aber definitiv keine konkreten Pläne, weil sich das wirklich von Version zu Version entscheidet. Man weiß jetzt gerade mal erst, dass man e10s für Firefox 46 für Nutzer ohne Add-ons plant. Was dann mit Firefox 47 ist, wird davon abhängen, wie gut das funktioniert und was man in den weiteren sechs Wochen alles beheben konnte. Auf einen bestimmten Release hinarbeiten, das tut man vielleicht, aber es gibt jetzt keinen Plan, der schon sagt, dass e10s ab Firefox XY für alle Nutzer standardmäßig aktiviert sein soll.
Ich denke nicht, dass es da irgendwas Besonderes geben wird. Wenn du die vielen Feiertage und Urlaube in dieser Phase berücksichtigst, und dass es im Dezember auch wieder eine Work Week geben wird, geht ja einiges an Zeit verloren. In dieser Zeit passiert jedes Jahr so wenig wie sonst nie. Zwölf Wochen zu dieser Zeit sind nicht so viel wie zwölf Wochen zu einer anderen Zeit. In dieser Phase des Jahres gab es in den letzten Jahren auch schon Verschiebungen, wo man von den sechs Wochen abgewichen ist, wenn auch nicht so stark, wie es jetzt geplant ist. 😉
@Marvin:
So einfach ist das nicht, Versionsnummern sind auch für die Kommunikation wichtig. Es hat in jedem Fall Vorteile, wenn man Versionen konkret benennen kann.
Nur annäherungsweise. Es gab in den vergangenen Jahren mehrere Verschiebungen.