Firefox ускоряет релизы вдвое — совместимость придётся проверять чаще
Firefox начинает переход с четырёхнедельного на двухнедельный выпуск версий с цикла Firefox 155 Beta. Как следует из описания перехода Mozilla, затем этапы Nightly, Beta и Release будут занимать по две недели; это подтверждает заявленное двукратное ускорение и означает более частые точки проверки совместимости.
Удваивать весь объём тестирования необязательно: полный прогон можно оставить для наиболее рискованных изменений, а каждый цикл закрывать автоматическими и короткими приёмочными проверками. Организациям, которым важнее редкие крупные перемены, подходит ESR: администраторская справка Firefox предусматривает ежегодные крупные версии этого канала и промежуточные исправления безопасности без большинства изменений интерфейса и функций.
Как устроено двухнедельное окно
Новый ритм не сводится к одному дню выпуска. Код переходит из основной ветки в Beta, стабилизируется на последовательных сборках, а после проверки окончательной сборки попадает в Release. Следующий цикл начинается почти сразу, поэтому ежемесячная контрольная дата больше не охватывает каждую версию обычного канала.
Процесс выпуска Mozilla устанавливает стандартный интервал в две недели, допускает его изменение из-за праздников или рабочих обстоятельств и предусматривает три настольные Beta в неделю — обычно пять за цикл. В конце цикла служба качества проверяет финальную сборку перед её переводом в ветку Release; внеплановые исправления могут добавить дополнительные Beta.
- Начало Beta: изучить изменения, затрагивающие собственный продукт, и запустить широкие автоматические проверки.
- Промежуточные сборки: повторить тесты изменённых или нестабильных участков, не прогоняя без причины всю ручную регрессию.
- Финальная сборка: выполнить короткую приёмку пакета, политик и критических пользовательских сценариев.
- Release: подтвердить работу в ограниченной рабочей группе и зафиксировать результат до следующего цикла.
Такой календарь увеличивает частоту решений, но не требует пяти одинаковых полных прогонов. Объём каждой проверки определяется не номером сборки, а риском изменений и тем, насколько команда зависит от интерфейсов браузера, веб-платформы или управляемой конфигурации.
План для разработчика расширения
Разработчику расширения имеет смысл сделать следующую Beta основной ранней точкой контроля, не дожидаясь стабильного выпуска. Минимальная матрица включает текущий Release и ближайшую Beta; Nightly стоит добавлять, если дополнение зависит от экспериментальных или быстро меняющихся возможностей и раннее обнаружение поломки оправдывает нестабильность этого канала.
В начале цикла следует проверить установку и обновление пакета, запуск фоновой логики, внедрение сценариев на страницы, запрошенные разрешения и основные действия пользователя. Для дополнения, связанного с конкретными сайтами, недостаточно подтвердить только загрузку расширения: автоматический прогон должен пройти критические страницы и операции, ради которых оно установлено.
Проверки удобно распределить по риску. Первая доступная Beta показывает, не затронули ли изменения платформы ключевые зависимости; промежуточные сборки позволяют подтвердить собственные исправления; финальная сборка подходит для короткой проверки готового пакета. Полную ручную регрессию стоит запускать при изменении используемых API, разрешений, элементов интерфейса браузера или сложного взаимодействия со страницами, а стабильные сценарии переносить в автоматизацию.
В результате частота контроля приблизится к частоте релизов, но трудозатраты не обязаны вырасти вдвое. Основная цена нового графика — более короткое время между обнаружением несовместимости и выпуском, а не требование дважды в месяц повторять весь прежний набор ручных действий.
Локализация получает более частые сроки
Для локализаторов минимальное время от перехода строк в Beta до выпуска сокращается с трёх недель до двух. При этом Mozilla не утверждает, что все строки будут появляться в последний момент или что за тот же период команда разработки должна подготовить вдвое больше функций: многие строки могут поступать раньше, а ожидаемый объём отдельного цикла будет меньше.
Меняется прежде всего ритм очереди. Если команда разбирала новые строки раз в месяц, часть сроков теперь будет проходить между такими проверками. Практичнее синхронизировать разбор с началом каждой Beta: сразу распределять новые строки, заранее отмечать спорную терминологию и проверять готовые переводы в интерфейсе до завершения цикла.
При ограниченных ресурсах приоритет следует задавать по пользовательскому риску. Сначала человеческую проверку получают строки основных настроек, предупреждений, разрешений и других критичных сценариев; второстепенные тексты можно обрабатывать следом. Это не расширяет объём локализации, а помогает уложить тот же процесс в более короткие и чаще повторяющиеся окна.
Что менять администратору обычного канала
Организации на обычном канале нужен контрольный контур, способный завершаться раз в две недели. В него следует включить внутренние веб-приложения, единый вход, прокси, сертификаты, печать, загрузки, обязательные расширения и корпоративные политики — именно ту комбинацию зависимостей, которая используется в рабочей среде.
Широкий приёмочный тест нужен не для каждой версии. Базовый цикл можно закрывать автоматической проверкой и коротким набором обязательных сценариев, а полную регрессию запускать при изменениях с высоким риском. Поэтапное развёртывание дополнительно отделяет проверку совместимости от массового обновления: новая версия сначала поступает ограниченной группе, затем расширяется после оценки ошибок и обращений.
Отдельно нужно пересмотреть расписания, инструкции и задания автоматизации, рассчитанные на четырёхнедельный интервал. Если окно допуска версии, сроки проверки Beta и ответственность за решение останутся месячными, технический выпуск будет происходить раньше организационного согласования.
Когда ESR действительно уменьшает нагрузку
ESR оправдан, если организации важнее стабильность интерфейса и поведения, чем быстрое получение новых функций. Масштабную проверку функциональных изменений тогда можно планировать вокруг ежегодной крупной версии и периода перехода на неё, сохраняя привычный годовой цикл подготовки.
При этом ESR не является каналом без обновлений. Промежуточные версии продолжают приносить исправления безопасности, поэтому для них нужен сокращённый регрессионный набор и обычная дисциплина развёртывания. Снижается частота крупных функциональных перемен, а не необходимость сопровождать браузер.
Администраторская страница, подтверждающая модель ESR, одновременно всё ещё описывает обычный Firefox как канал с четырёхнедельными крупными версиями. Это существенное расхождение между двумя официальными страницами: для нового ритма обычного канала следует использовать актуальный процесс выпуска и объявление о переходе, а сведения ESR отделять от устаревшего описания Release на той же странице.
Выбор определяется ценой частых изменений. Обычный Firefox требует каждые две недели подтверждать критические сценарии, но не обязательно повторять полную регрессию. ESR позволяет сосредоточить масштабную функциональную проверку вокруг ежегодного обновления, не отменяя тестирование и установку промежуточных исправлений безопасности.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.