Что на самом деле значит «последняя версия Chrome»: четыре канала, три версии, одна неделя

На неделе с 14 сентября 2026 года официальный блог релизов Chrome объявил, что всё перечисленное ниже одновременно доехало до реальных пользователей:

• 152.0.7977.130 в Extended Stable, для Windows и Mac
• 153.0.8010.47/.48 в Stable для десктопа, с 42 исправлениями безопасности
• 154.0.8037.44/.45 для Windows, описанная как «часть нашего релиза Early Stable для небольшого процента пользователей»
• 154.0.8037.49 для Android, «для небольшого процента пользователей»
• 154.0.8037.41 для Chrome на iOS, как обычный стабильный релиз для этой платформы

Три мажорные версии за одну неделю, и все они актуальные, ни одна не ошибочна. Кто угодно на любой из них ответит на вопрос «каким браузером вы пользуетесь?» словами «последний Chrome», и каждый из них скажет правду.

Именно поэтому строчка «Chrome, последняя версия» в шапке баг-репорта не несёт информации. Разобраться, что она скрывает, стоит десяти минут, потому что за этим фактом стоит целая категория багов, которые случаются у одних людей и не случаются у других.

Каналы так, как их определяет Google

У Chrome нет версии. У него есть каналы, и в каждый момент времени в каждом из них лежит своя мажорная версия. Вот что говорит собственная документация Google для администраторов:

• Stable «полностью протестирован командой тестирования Chrome, и его стоит использовать большинству ваших пользователей». Он обновляется «каждые 2-3 недели для минорных релизов и каждые 4 недели для мажорных».
• Пользователи Extended Stable «получают обновления функций реже, но всё равно получают исправления безопасности», и канал «обновляется каждые 8 недель». На практике большую часть цикла он отстаёт от Stable на одну мажорную версию, что и даёт разрыв 152 против 153 выше.
• Beta это «превью на 4-6 недель того, что придёт в Stable-версию Chrome».
• Dev это «превью на 9-12 недель», а Canary это «будущая версия Chrome, которая ещё находится в разработке».

Beta, Dev и Canary это выбор пользователя, и человек, который выбрал один из них, обычно об этом знает. А вот Stable и Extended Stable это как раз те два канала, которые важны для баг-репортов, потому что ни на одном из них никто ничего не выбирал: Extended Stable устанавливает администратор, для всей компании, часто годы назад, и люди, которые им пользуются, об этом понятия не имеют.

Поэтапный выкат: вот что удивляет людей

Канал тоже не версия, потому что релиз не доходит до всех пользователей канала сразу. Документация Chrome для разработчиков говорит об этом прямо:

Chrome использует поэтапный выкат для каждого канала, вместо того чтобы выпускать новую версию сразу для всех пользователей в надежде на лучшее. Это значит, что сначала обновление получает лишь небольшое число пользователей на каждом канале. Начаться это может всего с 1-5% пользователей и постепенно доходить до 100%.

Поэтому в любую среду два человека на Stable-канале Chrome, на одной и той же операционной системе, в одном офисе, могут оказаться на разных мажорных версиях, и никто из них ничего для этого не делал. У этой первой порции даже есть название, «Early Stable»: релиз 154 выше дошёл до пользователей Windows раньше, чем 153 успел докатиться до всех остальных.

На практике это оборачивается багом, который проявляется у нескольких процентов пользователей и ни у кого больше, в день, когда вы ничего не деплоили. Изнутри ваших логов это неотличимо от бага, который вызвали вы сами, а первое место, куда смотрит большинство команд, это их собственный последний релиз.

Слабо

Два пользователя сообщают, что датапикер сломан. Вчера мы ничего не деплоили. Значит, дело в данных.

Лучше

Два репорта, оба про Chrome 154.0.8037.44 на Windows, который вчера вышел как Early Stable для небольшого процента пользователей. Все остальные на 153.0.8010.47, и у них всё работает.

Мобильные версии это вообще не тот же браузер

Chrome на Android это Chrome: Blink, V8, тот же движок, что и на десктопе, на собственном графике релизов (153 вышла 15 сентября, 154 ушла небольшому проценту пользователей 16-го).

Chrome на iOS, наоборот, не тот же браузер. Правила App Store требуют, чтобы браузеры использовали системный веб-движок, поэтому Chrome на iPhone это WebKit в интерфейсе Chrome. Тот релиз выше, 154 на iOS, это новая версия интерфейса вокруг движка, который меняется вместе с iOS, а не вместе с Chrome. Баг с CSS, о котором сообщают со словами «Chrome на моём айфоне», на самом деле баг Safari, и воспроизвести его в Chrome на десктопе значит воспроизвести совсем другой браузер. Мы писали о том, что это делает с репортами, когда вышел Safari 27.

Как вытащить из репорта настоящую версию

Есть три способа, в порядке убывания шансов получить ответ.

Спросите chrome://version. Если ввести это в адресную строку, первая строка покажет полную сборку, плюс операционную систему и командную строку. Это одно копирование и вставка, работает на Android, и здесь нет двусмысленности. Именно это стоит спросить у разработчика или технически подкованного клиента.

Читайте user agent. Что-то на вашей стороне уже получает его с каждым запросом, так что спрашивать ничего не нужно. Ограничение, о котором стоит знать: несколько лет назад Chrome сократил эту строку, компоненты minor, build и patch в ней передаются нулями, так что вы получите Chrome/153.0.0.0, а не ту сборку, которая реально вышла. Полная сборка доступна, но только если её специально запросить: Sec-CH-UA-Full-Version-List это высокоэнтропийный client hint, который сервер получает только после запроса заголовком Accept-CH, либо который страница может прочитать через navigator.userAgentData.getHighEntropyValues(). Ни сокращённая строка, ни этот hint ничего не говорят о канале, потому что Extended Stable 152 и Stable 152 это одна и та же версия, полученная разными путями.

Спросите человека. Ответом будет «последняя версия», по всем причинам, перечисленным выше. И это не его вина: версия спрятана на три клика вглубь меню и ничего для него не значит, когда он её находит.

Общая черта всех трёх способов в том, что надёжный ответ не приходит через вопрос. Он приходит от чего-то на странице, что считывает браузер в момент, когда произошёл сбой, и это и есть аргумент в пользу того, чтобы репорт сам фиксировал своё окружение, а не полагался на опрос того, кто его подал. Наш собственный гайд по баг-репортам включает сборку браузера в шаблон именно по этой причине, и честно говоря, шаблон в этом смысле запасной вариант на случай, когда ничто не зафиксировало это автоматически.

Что это значит для тестирования

Из всего сказанного выше следуют два практических вывода, и оба идут вразрез с привычными советами.

Тестирование «последней версии Chrome» тестирует одну из как минимум трёх живых версий. Если среди ваших клиентов есть компания сколько-нибудь заметного размера, часть из них сидит на Extended Stable, на одну мажорную версию позади, и так восемь недель подряд. Функция, которая полагается на что-то, вышедшее в текущей мажорной версии, для этих пользователей специально сломана, а ваша тестовая матрица показывает зелёный свет. Статья про кросс-браузерное тестирование доказывает, что думать стоит движками, а не браузерами; версии это тот же самый аргумент, только уровнем ниже.

Поэтапный выкат тоже подозреваемый, и проверить это дёшево. Когда репорты начинают приходить без деплоя с вашей стороны, прежде чем перебирать собственные изменения, посмотрите, делят ли затронутые пользователи номер сборки, которого нет ни у кого больше. Блог релизов Chrome публичный и датированный, так что вопрос «выходило ли что-то для части пользователей в день, когда это началось» занимает минуту.

Что из этого стоит унести с собой

«Последняя версия» это слово о намерении, а не о софте. Версия, которая реально запущена, это факт, его можно узнать, и именно в этом разница между репортом, по которому можно действовать, и репортом, который отправляет вас перебирать собственную историю git на целый вечер.

Блог релизов Chrome это первоисточник, и его стоит держать в RSS-ридере, если поддержка браузера входит в вашу работу: Chrome Releases.