Для получения дополнительной информации обо всех изменениях, выпущенных в версии 2026.1, ознакомьтесь с:
Это первый релиз «ESR» (Extended Support Release) для Discourse, который заменяет старую ветку «stable». Сайты, отслеживающие ветку stable, будут обновлены с версии 3.5 до 2026.1 при следующем обновлении. Чтобы увидеть все изменения от версии 3.5 до 2026.1, используйте эту ссылку.
Также выпущены патч-релизы для других поддерживаемых версий:
2026.1.0 также является первым выпуском esr.
Для пользователей ранее существовавшей ветки stable (которая теперь является псевдонимом для esr) переход будет с версии 3.5.3 на 2026.1.0, а не на 3.5.4.
Итак, позвольте мне понять: у меня есть время до апреля (3 месяца), чтобы не обновляться. Когда v2026.1 будет устаревшей, моя текущая версия станет ESR, верно? Все эти изменения немного запутывают.
Да, если только они не используют тег v3.5.4, чтобы оставаться на версии 3.5.
Диаграмма на главной странице https://releases.discourse.org/ — лучший способ визуализировать ситуацию.
Какой бы поток выпусков вы ни выбрали, вам всё равно нужно регулярно обновляться для получения критических исправлений безопасности. Вопрос лишь в том, хотите ли вы получать новые функции и другие изменения вместе с исправлениями безопасности (если да, используйте release или latest), или предпочитаете более редкий, примерно полугодовой цикл обновлений (если да, используйте esr).
С новой схемой нумерации всё ещё рано, поэтому документация и инструменты будут продолжать развиваться по мере того, как мы адаптируемся к новой системе.
В декабре я обновлялся до версии v2026.0, а сейчас v2026.2. Правильно ли я понимаю, что в апреле она станет ESR?
Посетите главную страницу releases.discourse.org для получения всей информации о поддержке. Версия 2026.1 является текущим релизом с расширенной поддержкой и будет поддерживаться до сентября 2026 года.
Версия 2026.2 будет выпущена в феврале и будет получать исправления безопасности в течение 2 месяцев после этого. Она не будет релизом с расширенной поддержкой.
Является ли версия 2026.1.0 первым стабильным/ESR-релизом, в котором отказывается от поддержки iOS и других старых браузеров? Это достаточно крупное изменение, чтобы оно было указано в примечаниях к релизу. Однако в поле поиска «Подробные изменения» в конце я ничего не нашёл.
О, думаю, это потому, что вы ссылаетесь на список изменений между v2026.1.0-latest и v2026.1.0. Если изменить ссылку на v3.5.3 → v2026.1.0, то будет показано 2397 подробных изменений вместо всего 369. Для таких ESR-релизов действительно стоит ссылаться на последний ESR-релиз, а не на -latest (это что-то вроде RC?).
Я всё ещё не вижу, какое именно изменение явно указывало на отказ от поддержки старых браузеров, но хотя бы нашёл это: FIX: Update 'modern mobile' regex following iOS 15 support drop by davidtaylorhq · Pull Request #34792 · discourse/discourse · GitHub
Да 
Верно. Подавляющее большинство пользователей использует потоки latest или release в Discourse, поэтому сайт со списком изменений оптимизирован именно под них. Пользователи, выбирающие ESR, по сути «пропускают 5 версий» при каждом обновлении, поэтому вам нужно будет просмотреть изменения для каждой из этих промежуточных версий.
Вы можете сделать это, просматривая каждый промежуточный список изменений, или использовать фильтры для создания пользовательского списка изменений, охватывающего весь диапазон (как вы уже сделали). Возможно, мы сможем улучшить UX сайта релизов, добавив какую-то быструю ссылку для перехода к сравнению ESR → ESR.
Возвращаясь к предыдущему «стабильному» релизу, у нас тогда тоже не было «мега-списка изменений». Пользователям приходилось читать каждый промежуточный бета-список изменений, чтобы получить полную картину изменений. Так что, я думаю, мы движемся в правильном направлении — по крайней мере, теперь можно увидеть полный список изменений, даже если UX ещё не идеален.
На данный момент я добавил ссылку на это сравнение ESR → ESR в первый пост здесь:
Спасибо за обратную связь!
Независимо от того, идёт ли речь о переходе от конкретного релиза к другому или от произвольной точки в latest к актуальной версии latest, если изменение между коммитами x и y не может быть применено встроенным обновляющим механизмом и требует пересборки контейнера из нового образа, новая система примечаний к релизам сможет это определить и указать на необходимость пересборки?
Отдельно: будет ли встроенный обновляющий механизм предотвращать обновление и запрашивать пересборку?
Мое приблизительное понимание встроенного обновляющего механизма таково: после обновления Docker_manager он блокирует обновление Discourse, если требуется пересборка. Однако я не видел этого официально зафиксированным, и по anecdotalным данным это работало не совсем надёжно.
В частности, иногда после завершения обновления Docker_manager переход на страницу «Версии» показывал доступное для запуска обновление Discourse, и только после обновления страницы оно блокировалось. [Отмечу, что последний раз я наблюдал такое довольно давно, возможно, это уже исправлено.]
Необходимость полной пересборки связана с «базовым образом Docker» для Discourse, который полностью отделён от номера версии самого Discourse. Мы прибегали к ней, когда в образе Docker происходили критические изменения зависимостей на уровне операционной системы.
Поэтому включать эту информацию в примечания к выпуску ядра Discourse было бы сложно. Однако я понимаю ваше удивление и разочарование из-за невозможности обновиться через интерфейс. Возможно, мы сможем улучшить интерфейс в этом аспекте.
Я представляю это так:
Тем не менее, у нас сейчас есть и другие более важные задачи для общей работы над версионированием (например, совместимость темы/компонента и плагинов).
Однако я считаю, что не всегда иметь возможность использовать интерфейс для обновления — это нормально. Любой (частное лицо, компания или кто угодно), кто самостоятельно размещает Discourse, должен (или должен иметь) человека с хотя бы базовыми навыками администрирования сервера, чтобы выполнять такие задачи, как обновление хост-системы и пересборка Discourse.
На мой взгляд, самое важное следующее:
Пока интерфейс всегда обновляется корректно после обновления Docker_manager, то есть не оказывается в состоянии, когда он знает, что Docker_manager обновлён, но не знает, что требуется пересборка, я считаю, что оба этих условия уже выполняются.
Получится ли так, что Stable теперь будет получать обновления чаще? Мне очень нравилась стабильная работа ветки Stable по принципу «установил и забыл». Будет ли новая ветка ESR придерживаться той же философии, или стоит ожидать другого графика обновлений?
ESR будет примерно таким же, как и старая ветка stable. Подробную информацию о новой системе вы можете найти здесь:
Звучит отлично. Рад слышать, что ESR сохранит стабильность частоты обновлений. Спасибо!
Сообщение было разделено на новую тему: Ошибка при обработке маршрута: adminGroups.index
Есть ли причина, по которой Дашборд настойчиво требовал обновления, ссылаясь на критическую уязвимость безопасности, когда у меня была версия 2026.1? Сейчас стоит версия .2, так как требовалось обновить другие компоненты, но это показалось странным, учитывая, что .1 была ESR-версией.