News Browser: Mozilla entzerrt Firefox-Releaseplan

[S3veny]

Schon recht, aber auch da lässt sich eine Menge machen. Jemand brachte mal hier den Wortlaut Thunderbird wäre im Grunde schon fertig gestellt. Dem kann ich nicht zustimmen, eine Software ist nie fertig: Perfektion ist die letzte Nachkommastelle von Pi.

 

[IRON67]

...Jemand brachte mal hier den Wortlaut Thunderbird wäre im Grunde schon fertig gestellt. Dem kann ich nicht zustimmen, eine Software ist nie fertig...

Vermutlich interpretierst du einfach zu frei oder erinnerst dich falsch. Ich vermute sehr stark, dass derjenige meinte, dass TB ein stimmiges, funktionierendes Produkt mit allen wesentlichen Features ist, die der Normalanwender sich von einem Mailclient erwarten darf. Und das sehe ich auch so. Man kann bestimmte Arten von Anwendungen nicht unendlich weiter entwickeln, sofern nicht die Notwendigkeit besteht, sich geänderten technischen Standards und Gegebenheiten anzupassen.

TB tut, was er soll. Wer Erweiterungen braucht, soll die installieren. Wer dann immer noch etwas vermisst, soll sich nach Alternativen umsehen. Immer noch ein Feature und noch ein Gimmick in die Standardinstallation zu packen, weil ein paar Leute das gerade "in" finden, erhöht nur die Wahrscheinlichkeit von Fehlern.

 

[MotherPink]

Mozilla Thunderbird 38.5.1 Deutsch
7. Januar 2016

Mozilla Firefox 44.0 Deutsch
26. Januar 2016

38.6.0
Firefox Extended Support Release ESR

January 26, 2016

 

[T0a5tbr0t]

In einem klassischen Versionierungssschema steht ein Anheben des Zählers der Majorversion für eine große, grundlegende Änderung und/oder Weiterentwicklung. Die Minorversionen eben für unerhebliche Änderungen und/oder Sicherheitsaktualisierungen.

Und wer soll entscheiden, was wichtig ist? Wenn mehr als 400 Entwickler gleichzeitig an einem Projekt arbeiten, bleibt einem nichts anderes übrig, als Änderungen regelmäßig an Nutzer zu verteielen. Sonst bleiben kleine Änderungen liegen und müssen auf "wichtige Dinge" warten. So kann man allerdings keine vernünftige Software entwickeln. Änderungen müssen in absehbarer Zeit beim User landen. Damit planen Entwickler nunmal.

Nach Gefühl neue Versionen raushauen klappt vielleicht bei kleinen Projekten, bei den sich alle Entwickler persönlich absprechen können. Aber nicht bei Projekten, von denen Millionen von Menschen und unzählige Firmen von der Werteierentwicklung und dem Verteilen von Updates abhängen.

 

[DeusoftheWired]

Daß ein Browser im Jahr 2016 anders gepflegt wird als eine Tabellenkalkulation aus den 1980ern, ist mir auch klar. Das ist aber nicht das, was kritisiert wird. Kritisiert wird die Art Benennung der Änderungen.

Wenn Sicherheitshotfixes sowieso Minorversionen hochzählen, wieso sollte man dann die kleinen Änderungen wie von der 43 zur 44 nicht das gleiche tun lassen? Die letzte richtig große Änderung war Australis. Das hätte in meinen Augen eine 5 vor dem Punkt gerechtfertigt. WebRTC/Hello, Addon-Signing und Vergleichbares waren zwar ähnlich große Schritte, aber eben nicht groß genug. Dafür hätte man auch ein 5.3.0 akzeptieren können – aber nein, dank Chrome muß es ja 53 sein.

 

[Der-Orden-Xar]

Auch für dich gilt dann die Frage aus meienr Sig: Wo ist eigendlich der Unterschied zwischen 9.6.0 und 44.0? (9.6 würde sich ergeben, wenn nur die ESR-Versionen die 1. Stelle hochzählen würden und der Rest die 2.)
BTW: Ausrtalis als Version 5.0...
Massenhaft Verbesserungen, bei html5/Css/Canvas (inkl euer Engine dafür), schnellerer Sync, Bildlauf & Hardewerbeschleigung verbessert, DNT, "Stille" (AddOn)-Updates, SPDY, PDF-Viewer, besserer GC, allgemein besseres Speichermanagment, Click-to-Play, blahblahblah reicht nicht dafür? Da könnte man auch gleich die Versionsnummer im Stil von TeX handhaben

 

[T0a5tbr0t]

Dann werden viele Nutzer aber nur bei großen Versionssprüngen updaten. Das führt zur Fragmentierung die Nutzerbasis, was für Entwickler sehr schlecht ist. Auch weniger sichtbare Änderungen müssen regelmäßig bei Nutzern landen, sonst sind sie wertlos.
Wenn WebRTC z.B. nicht bei einer signifikanten Anzahl Nutzern landet, werden Webseiten es nicht verwenden. Dadurch mangelt es an Feedback und die Entwicklung fährt sich fest. Man kann Software nicht in einem Vakuum entwickeln und dann "fertig" ausliefern. Kleine, inkrementelle Schritte führen zu deutlich besseren Ergebnissen. Diese Schritte müssen in der Praxis aber erprobt werden.

Als durchschnittlicher Nutzer kann man Browser-interne Sachen oder neue Funktionen für Web-Content eh nicht einschätzen, ganz egal wie sie nummeriert werden. Daher sollte man es Nutzern auch nicht angewöhnen.
Browserentwickler müssen viel mehr bedenken, als nur die oberflächlichen Änderungen an der GUI. Wenn man daran alle Technischen Verbesserungen fest macht, bremst man diese extrem aus.
Und wenn Änderungen an der Oberfläche nicht will, nimmt man die ESR.

 

[DeusoftheWired]

Auch für dich gilt dann die Frage aus meienr Sig: Wo ist eigendlich der Unterschied zwischen 9.6.0 und 44.0?

Ob du’s glaubst oder nicht, aber genau den Spruch aus deiner Sig hab ich beim Tippen auch im Kopf gehabt, konnte mich aber um’s Verrecken nicht mehr an den Benutzernamen erinnern.

Massenhaft Verbesserungen, bei html5/Css/Canvas (inkl euer Engine dafür), schnellerer Sync, Bildlauf & Hardewerbeschleigung verbessert, DNT, "Stille" (AddOn)-Updates, SPDY, PDF-Viewer, besserer GC, allgemein besseres Speichermanagment, Click-to-Play, blahblahblah reicht nicht dafür? Da könnte man auch gleich die Versionsnummer im Stil von TeX handhaben

Viele, viele kleine bis mittelgroße Änderungen, aber nicht groß genug für eine Majorversion. Vielleicht ist ein Browser bzw. das Netz einfach auch zu schnellebig, um überhaupt langsame große Schritte zu erlauben. Obwohl … mit e10 steht da noch was aus.

Dann werden viele Nutzer aber nur bei großen Versionssprüngen updaten. Das führt zur Fragmentierung die Nutzerbasis, was für Entwickler sehr schlecht ist. Auch weniger sichtbare Änderungen müssen regelmäßig bei Nutzern landen, sonst sind sie wertlos.
Wenn WebRTC z.B. nicht bei einer signifikanten Anzahl Nutzern landet, werden Webseiten es nicht verwenden. Dadurch mangelt es an Feedback und die Entwicklung fährt sich fest. Man kann Software nicht in einem Vakuum entwickeln und dann "fertig" ausliefern. Kleine, inkrementelle Schritte führen zu deutlich besseren Ergebnissen. Diese Schritte müssen in der Praxis aber erprobt werden.

Die updatemuffligen Durchschnittsnutzer haben die meisten Programme mittlerweile vor sich selbst geschützt, indem sie sich selbst updaten. Bei Chrome ist es so weit, daß man ein Update schon gar nicht mehr mitbekommt, wenn man nicht an bestimmten Rädchen dreht. Wäre die Situation noch die von vor zehn Jahren, als man sich auf IT-Portalen über Aktualisierungen informieren und sie von Hand herunterladen mußte, würde ich dein Argument gelten lassen, aber so …

 

[T0a5tbr0t]

Genau das will man ja bewirken Die Versionen werden unabhängig von konkreten Funktionen und Änderungen kommen vorhersehbar bei Anwendern an. Irgendeine Nummer sagt eh nichts aus.

 

[Seppuku]

Auch für dich gilt dann die Frage aus meienr Sig: Wo ist eigendlich der Unterschied zwischen 9.6.0 und 44.0? (9.6 würde sich ergeben, wenn nur die ESR-Versionen die 1. Stelle hochzählen würden und der Rest die 2.)
BTW: Ausrtalis als Version 5.0...
[...]

Der Unterschied für den Endanwender ist der, dass er an Hand der Versionsnummer den Grad der Änderung ableiten kann.
Konkretes Beispiel: Wenn ich Firefox in der Version 3 benutzt habe, aus diversen Gründen auf einen anderen Browser gewechselt bin, konnte ich an Hand der Versionsnummer ableiten, ob sich ein neuer Versuch lohnt. Bevor ich mich mit den Details von Changelogs beschäftige, schaue ich mir bei jeder Software den Versionssprung an, um den Grad der Änderung abschätzen zu können.
Die Information bezüglich des Grads der Veränderung erhalte ich von 29 auf 37 oder 44 nicht. Und dann gilt es auch noch die Hauptveränderungen von Version 29 auf Version xx in zig verschiedenen Changelogs selbst herauszufiltern...

 

[S3veny]

Ich vermute sehr stark, dass derjenige meinte, dass TB ein stimmiges, funktionierendes Produkt mit allen wesentlichen Features ist, die der Normalanwender sich von einem Mailclient erwarten darf.

Sprich davon die umgangssprachliche Kurzform: Im Grunde fertig gestellt. War tatsächlich auch der genaue Wortlaut. Also selbst an TB gibt es noch eine Menge, und damit meine ich nicht Features (was nebenbei von Mozilla extrem elegant gelöst wurde indem Addons eingeführt wurden). Gut, was speziell einen Mail-Clienten angeht wüsste ich nun nicht, aber sehe das in sämtlichen anderen Bereichen "geänderte technische Standards und Gegebenheiten" nicht nur im Bereich Browser. Allein schon was Performance, Sicherheit, Bug-Fixing angeht.

Die Notwendig allerdings besteht ziemlich selten. HTML5-Support z.B ist keine Notwendigkeit, nur eine ziemlich begrüßenswerte Weiterentwicklung. Ein Texteditor ist weit weniger komplex als ein Mail-Client: Einen Text schreiben. Statt Word könnten viele auch Wordpad verwenden - Irgendeine Notwendigkeit besteht nicht - aber ich wette du benutzt auch etwas aus einer Office Suite.

---

Was die Nummerierung angeht; Ich hätte das in etwa als v4.45.02 gelöst. Wenn die Major-Nummer schon über 10 geht ist das gar nicht mehr ernst zu nehmen. Bei so vielen wirklich gravierenden Änderungen fängt man besser unter neuen Namen als v1 an. Ich wette da steckt eh noch haufenweiser alter, fehlerhafter, ungenutzter oder unsicherer Code drin der durch seine bloße Entfernung bei einer kompletten Überarbeitung schon eine nennenswerte Optimierung einbringt und den neuen Start rechtfertigen würde. Google schoss den Vogel ab, wechselt die Engine und bringt Chrome als v28 raus. Hoffe das passiert bei Mozilla mit Servo nicht.

 

[Lurtz]

Daß ein Browser im Jahr 2016 anders gepflegt wird als eine Tabellenkalkulation aus den 1980ern, ist mir auch klar. Das ist aber nicht das, was kritisiert wird. Kritisiert wird die Art Benennung der Änderungen.

Also Meckern um des Meckerns Willen, aufgrund einer Sache, die überhaupt nichts mit den Inhalten zu tun hat. Na wenn das das einzige Problem dabei ist...

Änderung an erster Versionsstelle = Major-Release mit neuen Features, Änderung an zweiter Versionsstelle = ESR-Update, Änderung an dritter Versionsstelle = Bugfixes und Sicherheitsupdates.
Und nein, die major Releases von Firefox enthalten nicht nur Bugfixes und Sicherheitsupdates, also entsprechen sie im Nummerierungsschema von Mozilla keiner dritten Versionsstelle.

Wenn Sicherheitshotfixes sowieso Minorversionen hochzählen, wieso sollte man dann die kleinen Änderungen wie von der 43 zur 44 nicht das gleiche tun lassen? Die letzte richtig große Änderung war Australis. Das hätte in meinen Augen eine 5 vor dem Punkt gerechtfertigt. WebRTC/Hello, Addon-Signing und Vergleichbares waren zwar ähnlich große Schritte, aber eben nicht groß genug. Dafür hätte man auch ein 5.3.0 akzeptieren können – aber nein, dank Chrome muß es ja 53 sein.

Ja, in deinen Augen. Mozilla sieht es anders.
Hast du eine Quelle dafür, dass das aufgrund von Chrome geschieht? Das ist eine beliebte Interpretation, die fleißig voneinander abgeschrieben wird, eine Quelle, die auf Mozilla verweist, habe ich aber noch nie gesehen.

 

[DeusoftheWired]

Also Meckern um des Meckerns Willen, aufgrund einer Sache, die überhaupt nichts mit den Inhalten zu tun hat. Na wenn das das einzige Problem dabei ist...

Manche Menschen möchten aus der Major- und Minorversion den Entwicklungsstand eines Programms ableiten können. Entschuldigung für diesen Wunsch.

Hast du eine Quelle dafür, dass das aufgrund von Chrome geschieht? Das ist eine beliebte Interpretation, die fleißig voneinander abgeschrieben wird, eine Quelle, die auf Mozilla verweist, habe ich aber noch nie gesehen.

Wird man offiziell nie aus irgendjemandem bei Mozilla herausbekommen, weil es ein Geständnis des Abkupferns von Chrome wäre. Und das sage ich als Firefox-Fanboy seit 2004. Der Wechsel zum Rapid Release Schedule geschah nur ca. 1,5 Jahre, nachdem Chrome das vorgemacht hatte und mit stetig steigenden Nutzerzahlen davongaloppierte, während vom Fuchs immer mehr Nutzer absprangen.

 

[Lurtz]

Manche Menschen möchten aus der Major- und Minorversion den Entwicklungsstand eines Programms ableiten können. Entschuldigung für diesen Wunsch.

Kannst du, das Schema dazu habe ich dir aufgeschrieben. Alles andere ist so willkürlich wie bei jeder andere Versionierung, rein daran kannst du nie den Entwicklungsstand ablesen.
Zudem ist die Versionierung bei Chromium noch viel undurchsichtiger.

Wird man offiziell nie aus irgendjemandem bei Mozilla herausbekommen, weil es ein Geständnis des Abkupferns von Chrome wäre. Und das sage ich als Firefox-Fanboy seit 2004. Der Wechsel zum Rapid Release Schedule geschah nur ca. 1,5 Jahre, nachdem Chrome das vorgemacht hatte und mit stetig steigenden Nutzerzahlen davongaloppierte, während vom Fuchs immer mehr Nutzer absprangen.

Haben sich die Nutzerzahlen seitdem positiver für Firefox entwickelt? Nein.
Viele große Browserhersteller bedienen sich mittlerweile dieser Rapid-Releases. Das hat nichts mit Abkupfern zu tun, es scheint aus anderen Gründen sinnvoll zu sein.

 

[Seppuku]

@ Lurtz

Dann erkläre es mir bitte nochmal, wie man von der ersten Stelle der aktuellen Nummerierung einen Major Release ableiten kann im Vergleich 29, 30 und 40. Auch wenn die Definition von Major Release einer gewissen Willkür unterworfen ist, sehe da keine wirkliche Logik.

 

[Der-Orden-Xar]

@Seppuku: Erklär du dann aber umgekehrt, warum Firefox 3.5 3.5 war und nicht wie ursprünglich geplant 3.1 oder agr 4.0? Und was rechtfertigt den "großen" Sprung von 3.0 auf 3.5 im Vergleich zum "Kleinen" von 3.5 auf 3.6.

Den Entwicklungsstand kann man mit ohne ohne "Rapid" ganz einfach ablesen: höhere Hauptnummer(n) = irgendwas wesentliches hat sich geändert, nur gibt es jetzt nur eine Hauptnummer und nicht zwei oder drei.

Und Rapid finde ich immer noch besser, als hier 20 mal auf CB zu lesen, das irgend wein Feature den Release einer neuen Version mit 50 Neuerungen verschiebt (so geschehen zumindest bei 3.0, 3.5, 4.0) und das ist auch die ofizelle Motivation dahinter - die schlechten Erfahrungen der Vergangenheit

 

[think->write!]

Die nutzer sprangen ab weil ff but alle 14+monate ein feature release hatte. Deshalb haben sie sich für das bestehende modell entschieden. Und damit dafür dass feature wenn sie fertig sind an die nutzer gehen. Und nicht auf major releases gewartet wird.

As dem grund wird jeder release als major release vermarktet und für den rest der nur bug fix will gibt es esr releases. Da man man can davon sein oder nicht. Ich sähe da lieber ein yy.MR.BFR versionsnummer schema. Was aber effektiv nix an dem Umstand ändern würde was in jedem release drin ist.

 

[grossernagus]

@ think->write!

Die Leute sind abgesprungen, weil es zu selten neue Hauptversionen gab? Glaubst du doch selbst nicht.

Ich denke eher, daß sich der Marktanteil des Chrome erhöht hat, weil der bei jeder Software mit installiert wurde und die DAUs das nicht abgewählt haben. Und dann war er Standardbrowser. Und den Android Siegeszug nicht vergessen.

 

[S3veny]

Warum Chrome so erfolgreich wurde, lässt relativ leicht hier ablesen:

1. https://simple.wikipedia.org/wiki/Usage_share_of_web_browsers
2. https://de.wikipedia.org/wiki/Datei:Timeline_of_web_browsers.svg
3. Es gibt nun mal mehr DAUs als Nerds.
4. Google vs Mozilla *hust*
5. Android

 

[HaZweiOh]

Daniel Glazman: Bestandsaufnahme und Strategie für Mozilla

Sehr lesenswert! Er beschreibt die Lage punktgenau!