Warum nicht mal testen

    Für mich ist das schon ein wenig "beklagen", wenn bzw weil ihm der aktuelle Releasezyklus zu lang erscheint ;)

    Zitat

    Dass Beta-Versionen bei Mozilla eine sehr hohe Qualität besitzen


    Eben genau deswegen - ich habe seltenst grobe Abweichungen von der Final, allenfalls klitzekleine Kleinigkeiten, die ich über Wochen hinweg aufarbeiten kann. Von mir aus können die auch weniger Betas und weniger Auroras erstellen, aber ganz weg, das ist doch "Käse" ;)

    Zitat

    Ich weiß nicht, wie du auf vier Wochen kommst.


    Keine Ahnung, schoss mir vorhin so in den Kopf, obwohl nur einmalig 6 Wochen Beta wegfallen, oops :mrgreen:
    Es waren 18 -> 12 Wochen, bevor die nächste Final alle 6 Wochen kommt.

    Ja, und es ist Spekulation, meine Spekulation - kann, muss aber nicht so sein. Tatsache wird aber dann sein, dass die zwischenzeitliche Entwicklungszeit für alle auch auf 12 Wochen reduziert, auch wenn sich nicht alle API im selben Rhythmus ändern müssten. Ich kann mich derzeit nur positiv überraschen lassen, was draus wird.

    Je weniger Zeit zwischen den Releases, desto weniger mögliche API-Änderungen. Einer der Gründe, wieso das aktuelle Modell besser ist als ein einziger Release pro Jahr. ;) Du musst bedenken, dass es von dem, was Mozilla umsetzen kann, keinen Unterschied macht, Mozilla schafft durch kürzere Entwicklungszyklen nicht plötzlich mehr in derselben Zeit. Also ist die Konsequenz wenn dann weniger Änderungen pro Versionssprung, also relativ gesehen weniger Firefox-Versionen, in denen überhaupt Änderungen notwendig sind. Aber das ist hier eh nicht wirklich entscheidend, da die aktive Hauptentwicklungszeit pro Version sechs Wochen beträgt, sowohl aktuell als auch im neuen Vorschlag. In Ausnahmefällen mag es mal eine API-Änderung noch in der Aurora-Version geben, aber das ist absolut nicht die Regel. Die Nightly-Phase ist die Zeit für Änderungen. Aurora und Beta dienen der Übersetzung und dem Reifeprozess, nicht der Entwicklung. De facto ist eine neue Firefox-Version nach sechs Wochen "fertig", alles danach ist nur noch Bugfixing, Übersetzen und ggfs. Rückgängigmachen von Änderungen oder selten mal ein Feature, welches unbedingt in Version XY ausgeliefert werden soll.

    In Richtung Beklagen lese ich in jedem Fall überhaupt nichts aus dem Artikel heraus. Er stellt halt fest, dass es bis zu 18 Wochen dauert, dass eine Änderung beim Endanwender landet. Das ist nicht wenig Zeit, da hat er absolut Recht. Aber er schreibt das nicht klagend, ganz im Gegenteil, er macht einen konstruktiven und sachlichen Gegenvorschlag. Den kann man gut oder nicht so gut finden. Ich find den Vorschlag sehr interessant. Die wichtigste Frage dürfte sein, wie sich das auf die Arbeit der Übersetzer auswirken würde, die eh schon gut ausgelastet sind.

    Zitat von Sören Hentzschel

    Aurora und Beta dienen der Übersetzung und dem Reifeprozess, […]

    Ich habe sowieso nie verstanden, warum man dafür zwei Kanäle benötigt.

    Zitat von Bernd.

    Zusätzlich dürften auch einige Entwickler von Erweiterungen abspringen, […]

    Ob die nun 12 oder 18 Wochen schnarchen macht doch wohl keinen Unterschied.

    Zitat von Sören Hentzschel

    Je weniger Zeit zwischen den Releases, desto weniger mögliche API-Änderungen.

    Sehe ich momentan nicht so.
    Wenn diese Änderungen nun 6 Wochen weniger auf der Halde liegen, wird die Anzahl der Änderungen nicht tangieren.

    Zitat von Sören Hentzschel

    Die wichtigste Frage dürfte sein, wie sich das auf die Arbeit der Übersetzer auswirken würde, die eh schon gut ausgelastet sind.

    Sie wird abnehmen, da es eine Baustelle weniger ist.
    Es wird auch der Aufwand von Mozilla geringer sein. D.h. man kann mit der gesparten Zeit etwas sinnvolleres anfangen.

    Die Arbeit für Übersetzer würde dadurch eher nicht abnehmen, da sich an sechs Wochen aktiver Entwicklung nichts ändert, viel mehr sind es sechs Wochen weniger Zeit, um die Übersetzung wirklich finalisiert zu haben. Vor allem gibt es keine einheitliche Strategie rund um den Globus, die Übersetzungsarbeit sieht in unterschiedlichen Ländern unterschiedlich aus. Man darf auch nicht vergessen, dass die Übersetzung vollkommen ehrenamtlich geschieht, durch freiwillige Mitglieder der Community, genau wie der Support hier, da will jede Änderung, die sich negativ auswirken kann, besser gut bedacht sein.

    Zitat

    Sehe ich momentan nicht so.
    Wenn diese Änderungen nun 6 Wochen weniger auf der Halde liegen, wird die Anzahl der Änderungen nicht tangieren.

    Das war auf den Fall bezogen, dass sich die Entwicklungszweig verkürzt. Was sie aber nicht tut. Darum meinte ich kurz darauf: "Aber das ist hier eh nicht wirklich entscheidend, da die aktive Hauptentwicklungszeit pro Version sechs Wochen beträgt, sowohl aktuell als auch im neuen Vorschlag". Das kam vielleicht nicht ganz deutlich hervor.

    Zitat von Sören Hentzschel

    Die Arbeit für Übersetzer würde dadurch eher nicht abnehmen,

    Eigentlich meinst du etwas anderes: die Leistung.
    Diese würde real ansteigen.

    Zitat von Sören Hentzschel

    Das kam vielleicht nicht ganz deutlich hervor.

    Oder auch von mir nicht hinreichend ausformuliert.
    Der Hauptentwicklungszweig Central wird bislang über zwei Stufen, Aurora und Beta, zum Release geschoben. Nach Messungen wird Aurora selten besucht, somit liegt der Gedanke nahe, selbige zu überspringen.

    Zitat von .Hermes

    Eigentlich meinst du etwas anderes: die Leistung.
    Diese würde real ansteigen.

    Ja, die Arbeit würde nicht abnehmen, die Leistung müsste u.U. steigen. Kommt darauf an, wie die Übersetzer arbeiten, ob sie das betreffen würde.

    Zitat von .Hermes

    Oder auch von mir nicht hinreichend ausformuliert.
    Der Hauptentwicklungszweig Central wird bislang über zwei Stufen, Aurora und Beta, zum Release geschoben. Nach Messungen wird Aurora selten besucht, somit liegt der Gedanke nahe, selbige zu überspringen.

    Ich dachte eher daran, dass meine Formulierung nicht gut genug war um deutlich zu machen, was ich meinte. :P Nämlich, dass das, was ich im ersten Teil dieses Abschnittes erklärte, hier nicht wirklich relevant ist, da sich im vorgeschlagenen Modell die eigentliche Entwicklungszeit nicht verkürzt, sprich es in Bezug auf API-Änderungen keine nennenswerten Unterschiede geben sollte. Was du ja auch in deinem Beitrag sagtest.