Cosa significa davvero "l'ultima versione di Chrome": quattro canali, tre versioni, una settimana

Nella settimana del 14 settembre 2026, il blog ufficiale dei rilasci di Chrome ha annunciato che tutto quanto segue stava arrivando agli utenti reali:

• 152.0.7977.130 su Extended Stable, per Windows e Mac
• 153.0.8010.47/.48 su Stable desktop, con 42 correzioni di sicurezza
• 154.0.8037.44/.45 su Windows, descritta come “parte del nostro rilascio early stable a una piccola percentuale di utenti”
• 154.0.8037.49 su Android, “a una piccola percentuale di utenti”
• 154.0.8037.41 su Chrome per iOS, come normale rilascio Stable su quella piattaforma

Tre versioni principali, in una settimana, tutte attuali, nessuna sbagliata. Chiunque si trovi su una di queste versioni, se interrogato su quale browser stia usando, risponderebbe “l’ultima versione di Chrome”, e in ogni caso sarebbe la verità.

Ecco perché “Chrome, ultima versione” in cima a una segnalazione di bug non è un’informazione. Vale la pena dedicare dieci minuti a capire cosa nasconde, perché la sua struttura spiega un’intera categoria di bug che si presentano ad alcune persone e non ad altre.

I canali, secondo la definizione di Google

Chrome non ha una versione. Ha dei canali, ciascuno dei quali contiene in ogni momento una versione principale diversa. Dalla documentazione ufficiale di Google per gli amministratori:

• Stable “è stato testato a fondo dal team di test di Chrome e dovrebbe essere usato dalla maggior parte degli utenti”. Si aggiorna “ogni 2-3 settimane per i rilasci minori, e ogni 4 settimane per quelli principali”.
• Gli utenti di Extended Stable “ricevono aggiornamenti delle funzionalità meno frequentemente, ma continuano a ricevere le correzioni di sicurezza”, e il canale viene “aggiornato ogni 8 settimane”. In pratica resta una versione principale indietro rispetto a Stable per la maggior parte del ciclo, il che corrisponde esattamente al divario tra 152 e 153 visto sopra.
• Beta è “un’anteprima di 4-6 settimane di ciò che arriverà nella versione Stable di Chrome”.
• Dev è “un’anteprima di 9-12 settimane”, mentre Canary è “una versione futura di Chrome ancora in sviluppo”.

Beta, Dev e Canary sono su base volontaria, e chi ne ha scelto uno di solito lo sa. Stable ed Extended Stable sono i due canali che contano per le segnalazioni di bug, perché in nessuno dei due c’è stata una scelta consapevole: Extended Stable viene impostato da un amministratore, per l’intera azienda, spesso anni prima, e chi lo usa non ne ha idea.

I rilasci a scaglioni, la parte che sorprende di più

Anche il canale non è una versione, perché un rilascio non raggiunge tutti gli utenti del canale nello stesso momento. La documentazione per sviluppatori di Chrome lo dice senza mezzi termini:

Chrome utilizza rilasci a scaglioni per ogni canale, invece di distribuire una nuova versione a tutti gli utenti in una sola volta, sperando che vada tutto bene. Questo significa che, inizialmente, solo un piccolo numero di utenti di ciascun canale di rilascio riceve l’aggiornamento. Si può partire anche solo dall’1-5% degli utenti, per poi salire gradualmente fino al 100%.

Quindi in un qualsiasi mercoledì, due persone su Chrome Stable, sullo stesso sistema operativo, nello stesso ufficio, possono trovarsi su versioni principali diverse, senza che nessuna delle due abbia fatto nulla per causarlo. “Early Stable” è proprio quella prima fetta con un nome: il rilascio 154 citato sopra è arrivato agli utenti Windows prima che il 153 finisse di essere distribuito a tutti gli altri.

La conseguenza pratica è un bug che compare per una piccola percentuale degli utenti e per nessun altro, a partire da un giorno in cui non è stato effettuato alcun deploy. Dall’interno dei log, risulta indistinguibile da un bug causato internamente, e il primo posto in cui la maggior parte dei team guarda è il proprio ultimo rilascio.

Debole

Due utenti segnalano che il datepicker è rotto. Ieri non abbiamo fatto deploy. Deve essere un problema di dati.

Meglio

Due segnalazioni, entrambe su Chrome 154.0.8037.44 su Windows, uscito come Early Stable ieri per una piccola percentuale di utenti. Tutti gli altri sono su 153.0.8010.47 e funzionano correttamente.

I dispositivi mobili non sono affatto lo stesso browser

Chrome su Android è Chrome: Blink, V8, lo stesso motore del desktop, su un proprio canale di rilascio (153 il 15 settembre, 154 per una piccola percentuale il 16).

Chrome su iOS non lo è. Le regole dell’App Store di Apple impongono ai browser di usare il motore web di sistema, quindi Chrome su un iPhone è WebKit con l’interfaccia di Chrome. Il rilascio citato sopra, 154 su iOS, è una nuova versione dell’interfaccia attorno a un motore che cambia quando cambia iOS, non quando cambia Chrome. Un bug CSS segnalato da “Chrome sul mio iPhone” è un bug di Safari, e riprodurlo su Chrome desktop significa riprodurlo su un browser diverso. Abbiamo scritto di cosa questo comporta per le segnalazioni nell’articolo pubblicato quando è uscito Safari 27.

Estrarre la versione reale da una segnalazione

Ci sono tre modi, in ordine decrescente di probabilità di ottenere una risposta.

Chiedere chrome://version. Digitato nella barra degli indirizzi, restituisce la build completa sulla prima riga, oltre al sistema operativo e alla riga di comando. È un solo copia e incolla, funziona su Android, ed è inequivocabile. È la cosa giusta da chiedere a uno sviluppatore o a un cliente tecnico.

Leggere lo user agent. Qualcosa lato server lo sta già ricevendo a ogni richiesta, quindi non c’è nulla da chiedere. Il limite da conoscere è che Chrome ha ridotto la stringa qualche anno fa: i componenti minor, build e patch vengono inviati come zeri, quindi quello che si ottiene è Chrome/153.0.0.0 e non la build effettivamente installata. La build completa è disponibile, ma solo se la si richiede esplicitamente: Sec-CH-UA-Full-Version-List è un client hint ad alta entropia, che un server riceve solo dopo averlo richiesto con un header Accept-CH, oppure che una pagina può leggere tramite navigator.userAgentData.getHighEntropyValues(). Né la stringa ridotta né il client hint dicono nulla sul canale, perché Extended Stable 152 e Stable 152 sono la stessa versione raggiunta per strade diverse.

Chiedere alla persona. Il che restituisce “l’ultima versione”, per tutti i motivi visti sopra. Non è colpa sua: la versione è nascosta tre clic dentro un menu e, quando la trova, non significa nulla per lei.

Lo schema comune a questi tre metodi è che le risposte affidabili non derivano dal chiedere. Derivano da qualcosa che legge il browser nel momento stesso in cui si verifica l’errore, il che è l’argomento a favore di segnalazioni che catturano da sole il proprio ambiente, invece di dover intervistare chi le ha inviate. La nostra guida alla segnalazione dei bug include la build del browser nel modello proprio per questo motivo, e la lettura onesta è che il modello è un ripiego per i casi in cui nulla l’ha catturata automaticamente.

Cosa significa questo per il testing

Da quanto detto emergono due conclusioni pratiche, che vanno nella direzione opposta rispetto ai consigli abituali.

Testare “l’ultima versione di Chrome” significa testare una di almeno tre versioni attive. Se tra i clienti c’è un’azienda di qualsiasi dimensione, alcuni di loro sono su Extended Stable, una versione principale indietro, per otto settimane di fila. Una funzionalità che dipende da qualcosa introdotto nella versione principale corrente risulta rotta, di proposito, per quegli utenti, e la matrice di test segna verde lo stesso. L’articolo sul cross-browser testing sostiene che conviene ragionare in termini di motori piuttosto che di browser; l’asse delle versioni è lo stesso ragionamento un livello più in basso.

Un rilascio a scaglioni è un sospetto, ed è economico da verificare. Quando le segnalazioni iniziano senza che ci sia stato un deploy, prima di passare in rassegna le proprie modifiche conviene controllare se gli utenti coinvolti condividono un numero di build che nessun altro ha. Il blog dei rilasci di Chrome è pubblico e datato, quindi rispondere alla domanda “è stato distribuito qualcosa a una fetta di utenti nel giorno in cui è iniziato il problema?” richiede un minuto.

Cosa portarsi via

“Ultima” è una parola che riguarda l’intenzione, non il software. La versione effettivamente in esecuzione è un fatto, è conoscibile, ed è la differenza tra una segnalazione su cui si può agire e una che manda a passare un pomeriggio nella propria cronologia git.

Il blog dei rilasci di Chrome è la fonte primaria, e vale la pena tenerlo in un feed reader se si supporta un browser per lavoro: Chrome Releases.