Переключение между каналами/версиями выпуска Discourse

[Discourse]

В этом руководстве объясняется, как настроить канал выпуска для вашего экземпляра Discourse.

Требуемый уровень пользователя: Системный администратор

Требуется доступ к консоли.

Управление каналом вашего экземпляра Discourse определяет частоту и тип получаемых обновлений. В этом руководстве описаны доступные каналы и приведен пошаговый подход к изменению ветки в вашей настройке.

Краткое описание

Discourse предлагает несколько каналов для отслеживания обновлений программного обеспечения: latest, release и esr. В этой документации объясняется назначение каждого из них, их ключевые особенности и способы их настройки в вашем экземпляре Discourse. Для иллюстрации каналов см. releases.discourse.org.

Поддерживаемые каналы

latest

Рекомендуемый канал по умолчанию
Этот канал предоставляет последние исправления ошибок и обновления совместимости для плагинов. Каждый успешный коммит из ветки main тестируется сборочным сервером и добавляется в ветку latest после успешной проверки.

• Подходит для сайтов, которые хотят быть в курсе последних обновлений.
• Сайты могут обновляться вручную в любое время.

release

Для сайтов, предпочитающих ежемесячные выпуски

Канал release отслеживает последний ежемесячный выпуск Discourse. Каждый месяц из ветки latest создается ветка выпуска (например, release/2026.2), предоставляющая стабильную версию.

• Выпускается примерно раз в месяц.
• Каждый выпуск получает критические исправления в течение двух полных циклов выпусков.

esr

Расширенная поддержка выпуска (Extended Support Release)

Тег esr отслеживает последний выпуск с расширенной поддержкой, предназначенный для сайтов, которые отдают приоритет долгосрочной стабильности и безопасности, а не частым обновлениям.

• Объявляется примерно каждые 6 месяцев на основе ежемесячных выпусков.
• Получает исправления безопасности и критические обратные портирования в течение длительного периода.
• Может иметь ограниченную совместимость с плагинами сообщества и компонентами тем.

Примечание: Отсутствие регулярных обновлений обслуживания может оставить некоторые функции устаревшими или визуально несовместимыми.

Устаревшие псевдонимы

Для обратной совместимости следующие старые имена веток/тегов по-прежнему работают, но считаются устаревшими:

• tests-passed → latest
• beta → release
• stable → esr

Другие ветки или ссылки

Отслеживание других веток (например, конкретных веток release/YYYY.M или SHA-хешей коммитов) возможно, но требует экспертизы. Эти ветки получают критические исправления только в течение ограниченного периода.

Инструкции по настройке канала

n
Выполните следующие шаги, чтобы настроить желаемую ветку в вашем экземпляре Discourse:

1. Доступ к файлу конфигурации
   Откройте файл конфигурации app.yml, выполнив следующие команды в консоли:

cd /var/discourse
nano containers/app.yml

Редактор nano откроет файл конфигурации.
2. Редактирование отслеживаемой ветки
Найдите параметр версии, поискав слово “version” в файле:

params:  
## Какую ревизию Git должен использовать этот контейнер? (по умолчанию: latest)  
#version: latest

• Уберите комментарий со строки version.
• Замените latest на желаемое имя ветки или тега (например, esr). Пример:

params:  
## Какую ревизию Git должен использовать этот контейнер? (по умолчанию: latest)  
version: esr  

3. Сохранение и выход

• Нажмите Ctrl+O, чтобы сохранить изменения.
• Нажмите Enter, чтобы подтвердить.
• Используйте Ctrl+X, чтобы выйти из редактора.

4. Пересборка контейнера
   После внесения и сохранения изменений пересоберите контейнер, чтобы применить новую конфигурацию:

./launcher rebuild app

Пересборка вызовет временный простой

[ghorbani (Aref)]

@Discourse

cd /var/discourse
git pull
nano containers/app.yml

Является ли git pull необходимым шагом или это излишняя команда, оставшаяся от старой документации, как в случае с обновлением Discourse (Ручное обновление Discourse и образа Docker до последней версии)?

[merefield (Robert)]

По моему опыту, git pull бывает иногда полезен — например, это было необходимо, когда мы переходили с yarn на pnpm…

Обычно нет необходимости беспокоиться о регулярной пересборке.

[ghorbani (Aref)]

Полезно знать! Спасибо за информацию.

[merefield (Robert)]

что я обычно делаю , это пытаюсь пересобрать, и если это по какой-то неочевидной причине не получается, сначала пробую выполнить git pull — это занимает немного времени.

[david (David Taylor)]

В теории это никогда не должно требоваться. Лаунчер автоматически обнаружит устаревшую копию и выполнит git pull самостоятельно:

launcher

[ghorbani (Aref)]

Спасибо за подробности. Действительно, это имеет смысл. Попробую без git pull и сообщу вам о результатах.

[Ed_S]

Это странно. Код, о котором идет речь, датируется 2015 годом, мой форум — 2018-м, и тем не менее я довольно уверен, что здесь обсуждалось несколько случаев, когда требовалось выполнить git pull.

Что касается меня, я всегда делаю git pull, если не забуду — это ничего мне не стоит.

[david (David Taylor)]

Это часто упоминается, я думаю, из-за этих исторических документов. Я не считаю, что когда-либо видел доказательства того, что это действительно помогает.

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

[Ed_S]

@Discourse

## Какую ревизию Git следует использовать этому контейнеру? (по умолчанию: latest)  
#version: latest

Поскольку в файле yml используется version, а не supported tracking branch, не стоит ли добавить (version) в заголовок темы?

[ghorbani (Aref)]

Меня также немного шокировала дата. Но, проверив историю версий, я увидел, что последнее обновление было 18 мая.

[david (David Taylor)]

Я попытался обновить исходное сообщение, чтобы использовать нашу современную терминологию «канал», и убрать некоторые ненужные упоминания git pull.

[merefield (Robert)]

Должно быть, существует хотя бы один крайний случай, потому что в очень редких ситуациях это определённо «помогло мне преодолеть трудности».

Неужели это происходит, когда основной скрипт изменяется при определённых условиях?