Was „aktuellstes Chrome" wirklich bedeutet: vier Kanäle, drei Versionen, eine Woche

In der Woche vom 14. September 2026 verkündete Chromes eigener Release-Blog, dass alle folgenden Versionen an echte Nutzer ausgeliefert wurden:

• 152.0.7977.130 an Extended Stable, für Windows und Mac
• 153.0.8010.47/.48 an Stable Desktop, mit 42 Sicherheitskorrekturen darin
• 154.0.8037.44/.45 an Windows, beschrieben als „Teil unseres Early-Stable-Release für einen kleinen Prozentsatz der Nutzer”
• 154.0.8037.49 an Android, „für einen kleinen Prozentsatz der Nutzer”
• 154.0.8037.41 an Chrome auf iOS, als dortiges reguläres Stable-Release

Drei Hauptversionen in einer Woche, alle aktuell, keine davon falsch. Wer auch immer eine davon nutzt, würde die Frage „Welchen Browser verwenden Sie?” mit „das aktuellste Chrome” beantworten, und jeder von ihnen würde die Wahrheit sagen.

Deshalb ist „Chrome, aktuellste Version” am Kopf eines Bugreports keine Information. Es lohnt sich, zehn Minuten zu investieren, um zu verstehen, was sich dahinter verbirgt, denn diese Struktur erklärt eine ganze Kategorie von Fehlern, die manche Nutzer betreffen und andere nicht.

Die Kanäle, wie Google sie definiert

Chrome hat keine Version. Es hat Kanäle, von denen jeder zu jedem Zeitpunkt eine andere Hauptversion enthält. Aus Googles eigener Dokumentation für Administratoren:

• Stable „wurde vom Chrome-Testteam vollständig getestet und sollte von den meisten Ihrer Nutzer verwendet werden”. Der Kanal wird „alle 2-3 Wochen für Nebenversionen und alle 4 Wochen für Hauptversionen” aktualisiert.
• Nutzer von Extended Stable „erhalten seltener Feature-Updates, bekommen aber weiterhin Sicherheitskorrekturen”, und der Kanal wird „alle 8 Wochen aktualisiert”. In der Praxis liegt er die meiste Zeit des Zyklus eine Hauptversion hinter Stable zurück, was der oben genannten Lücke zwischen 152 und 153 entspricht.
• Beta ist „eine 4-6-wöchige Vorschau auf das, was als Nächstes in die Stable-Version von Chrome kommt”.
• Dev ist „eine 9-12-wöchige Vorschau”, und Canary ist „eine zukünftige Version von Chrome, die sich noch in der Entwicklung befindet”.

Beta, Dev und Canary sind Opt-in, und wer sich für einen davon entschieden hat, weiß das meist auch. Für Bugreports zählen Stable und Extended Stable, denn bei beiden hat niemand aktiv etwas gewählt: Extended Stable wird von einem Administrator festgelegt, für das gesamte Unternehmen, oft schon vor Jahren, und die Nutzer, die ihn verwenden, haben keine Ahnung davon.

Gestaffelte Rollouts: der Teil, der die meisten überrascht

Auch ein Kanal ist keine Version, denn ein Release erreicht nicht alle Nutzer eines Kanals gleichzeitig. Chromes Entwicklerdokumentation spricht das unverblümt an:

Chrome verwendet für jeden Kanal gestaffelte Rollouts, anstatt eine neue Version allen Nutzern auf einmal zur Verfügung zu stellen und auf das Beste zu hoffen. Das bedeutet, dass zunächst nur eine kleine Anzahl von Nutzern jedes Release-Kanals ein Update erhält. Das kann bei nur 1-5 % der Nutzer beginnen und sich schrittweise auf 100 % steigern.

So können an einem x-beliebigen Mittwoch zwei Personen mit Stable-Chrome, auf demselben Betriebssystem, im selben Büro, unterschiedliche Hauptversionen haben, ohne dass einer von beiden etwas dafür getan hat. „Early Stable” ist dieses erste Segment mit einem Namen: Das oben genannte 154-Release ging an Windows-Nutzer, bevor 153 bei allen anderen fertig ausgerollt war.

In der Praxis bedeutet das einen Fehler, der bei ein paar Prozent Ihrer Nutzer auftritt und sonst bei niemandem, und zwar an einem Tag, an dem Sie nichts deployt haben. Aus Ihren Logs heraus ist das nicht von einem selbst verursachten Fehler zu unterscheiden, weshalb die meisten Teams zuerst bei ihrem eigenen letzten Release nachsehen.

Schwach

Zwei Nutzer melden, dass der Datepicker kaputt ist. Wir haben gestern nichts deployt. Muss an den Daten liegen.

Besser

Zwei Meldungen, beide Chrome 154.0.8037.44 unter Windows, das gestern als Early Stable an einen kleinen Prozentsatz ausgerollt wurde. Alle anderen sind auf 153.0.8010.47 und haben keine Probleme.

Die mobilen Versionen sind gar nicht derselbe Browser

Chrome auf Android ist Chrome: Blink, V8, dieselbe Engine wie am Desktop, auf einer eigenen Release-Schiene (153 am 15. September, 154 für einen kleinen Prozentsatz am 16.).

Chrome auf iOS dagegen nicht. Apples App-Store-Regeln verlangen, dass Browser die System-Web-Engine verwenden, sodass Chrome auf einem iPhone WebKit mit der Chrome-Oberfläche ist. Das oben genannte Release, 154 auf iOS, ist eine neue Version dieser Oberfläche um eine Engine herum, die sich ändert, wenn sich iOS ändert, nicht wenn sich Chrome ändert. Ein CSS-Fehler, der aus „Chrome auf meinem iPhone” gemeldet wird, ist ein Safari-Fehler, und ihn in Chrome am Desktop zu reproduzieren, reproduziert einen anderen Browser. Wir haben darüber geschrieben, was das für Reports bedeutet, als Safari 27 erschien.

Die tatsächliche Version aus einem Report herausbekommen

Es gibt drei Wege, in absteigender Reihenfolge der Wahrscheinlichkeit, tatsächlich eine Antwort zu bekommen.

Nach chrome://version fragen. In die Adressleiste eingegeben, liefert das in der ersten Zeile den vollständigen Build, dazu das Betriebssystem und die Kommandozeile. Es ist ein einziges Kopieren und Einfügen, es funktioniert auch auf Android, und es ist eindeutig. Das ist die richtige Frage an einen Entwickler oder eine technisch versierte Kundin.

Den User-Agent auslesen. Auf Ihrer Seite kommt der bei jedem Request ohnehin schon an, es gibt also nichts, wonach Sie fragen müssten. Die Einschränkung, die man kennen sollte: Chrome hat den String vor einigen Jahren gekürzt. Die Komponenten für Minor-, Build- und Patch-Version werden als Nullen gesendet, sodass Sie Chrome/153.0.0.0 bekommen und nicht den tatsächlich ausgelieferten Build. Der vollständige Build ist verfügbar, aber nur, wenn Sie aktiv danach fragen: Sec-CH-UA-Full-Version-List ist ein High-Entropy-Client-Hint, den ein Server nur nach Anforderung über einen Accept-CH-Header erhält, oder den eine Seite über navigator.userAgentData.getHighEntropyValues() auslesen kann. Weder der gekürzte String noch der Hint sagt etwas über den Kanal aus, denn Extended Stable 152 und Stable 152 sind dieselbe Version auf unterschiedlichen Wegen.

Die Person selbst fragen. Das liefert aus allen oben genannten Gründen „die aktuellste”. Das ist nicht ihre Schuld: Die Version liegt drei Klicks tief in einem Menü vergraben und bedeutet ihr nichts, selbst wenn sie sie findet.

Das Muster, das sich durch alle drei zieht: Die zuverlässigen Antworten entstehen nicht durch Nachfragen. Sie entstehen dadurch, dass etwas auf der Seite den Browser in dem Moment ausliest, in dem der Fehler passiert, und genau das ist das Argument dafür, den Report seine eigene Umgebung erfassen zu lassen, statt die Person zu befragen, die ihn eingereicht hat. Unser eigener Leitfaden für Bugreports nimmt aus diesem Grund den Browser-Build ins Template auf, und ehrlich gelesen ist das Template damit ein Fallback für den Fall, dass nichts ihn automatisch erfasst hat.

Was das fürs Testen bedeutet

Aus dem Vorstehenden ergeben sich zwei praktische Schlussfolgerungen, die in die entgegengesetzte Richtung der üblichen Empfehlung weisen.

Wer „das aktuellste Chrome” testet, testet eine von mindestens drei live laufenden Versionen. Wenn zu Ihren Kunden ein Unternehmen beliebiger Größe zählt, ist ein Teil davon auf Extended Stable unterwegs, eine Hauptversion zurück, und zwar jeweils acht Wochen lang. Ein Feature, das auf etwas beruht, das erst in der aktuellen Hauptversion ausgeliefert wurde, ist für diese Nutzer absichtlich kaputt, während Ihre Testmatrix grün zeigt. Der Artikel Cross-Browser-Testing plädiert dafür, in Engines statt in Browsern zu denken; die Versionsachse ist dasselbe Argument eine Ebene tiefer.

Ein gestaffelter Rollout ist ein Verdächtiger, und er ist billig zu überprüfen. Wenn Reports ohne eigenes Deployment einsetzen, prüfen Sie, bevor Sie Ihre eigenen Änderungen durchgehen, ob die betroffenen Nutzer eine Build-Nummer gemeinsam haben, die sonst niemand hat. Chromes Release-Blog ist öffentlich und datiert, sodass die Frage „Ist an dem Tag, an dem das begann, etwas an eine Teilmenge der Nutzer ausgerollt worden?” in einer Minute beantwortet ist.

Was man daraus mitnehmen sollte

„Aktuellste” ist ein Wort über Absicht, nicht über Software. Die tatsächlich laufende Version ist eine Tatsache, sie ist feststellbar, und sie macht den Unterschied zwischen einem Report, auf den Sie reagieren können, und einem Report, der Sie einen Nachmittag lang durch die eigene Git-Historie schickt.

Chromes Release-Blog ist die Primärquelle, und es lohnt sich, ihn im Feedreader zu haben, wenn Sie beruflich einen Browser unterstützen: Chrome Releases.