На прошлой неделе команда браузера Brave подтвердила, что добавляет официальный способ обхода ограничений, благодаря которому пользователи смогут продолжить использовать популярные расширения Manifest V2, включая uBlock Origin. Firefox, как и Brave, также не собирается следовать примеру Google, которая вскоре полностью прекратит поддержку таких расширений и удалит их.
Однако в одном вопросе Mozilla все же рассматривает возможность последовать примеру Google: организация намерена перейти на двухнедельный график выпуска новых версий Firefox.
Mozilla планирует переход на двухнедельный график релизов
Об этом сообщил директор Mozilla Сильвестр Ледрю (Sylvestre Ledru) в новом обращении к команде разработчиков Firefox. Пока переход носит экспериментальный характер.
В сообщении говорится:
Мы планируем перевести Firefox для настольных компьютеров и Android с четырёхнедельного графика релизов на двухнедельный начиная с сентября 2026 года.
Это будет эксперимент. Наша цель – чаще предоставлять готовым изменениям возможность попасть к пользователям, одновременно сделав процесс выпуска новых версий более предсказуемым и снизив необходимость срочно переносить изменения в релизные ветки.
Сейчас планируется выпустить Firefox 155 1 сентября 2026 года вместо 15 сентября.
Chrome и Edge переходят первыми
Первым на двухнедельный график релизов перешёл Google Chrome. Компания объявила об этом в марте 2026 года. В прошлом месяце аналогичное решение приняла Microsoft.
Хотя Google первой объявила о переходе на новый график, фактически компания начнёт внедрять его позже остальных. Chrome перейдёт на двухнедельный цикл релизов 8 сентября. Первой станет Microsoft Edge – новая схема начнёт действовать 27 августа, всего за несколько дней до выхода Firefox 155.
Качество важнее скорости
Несмотря на ускорение графика, Ледрю заверил, что Mozilla не будет выпускать незавершённые функции только ради соблюдения новых сроков. Компания намерена ставить качество выше скорости.
Он написал:
Это не означает, что теперь всю работу нужно выполнять в два раза быстрее. Незавершённые изменения не следует выпускать в спешке, а разработка функций по-прежнему может занимать столько времени, сколько необходимо для их полноценного тестирования и доработки.