Мы обсуждали внутри компании несколько идей по улучшению страницы «Обновление Discourse».
Одна из идей — показывать историю обновлений со ссылками на списки изменений (changelogs) для разницы между ними (это может помочь понять изменения, которые вы замечаете после обновления).
Вот ещё пара идей/замечаний, которые только что возникли:
Какие ещё идеи есть у участников?
Привет,
Вот идея, к которой я постоянно возвращаюсь: большая часть раздражения по поводу «новая версия доступна при каждом коммите» возникает из-за того, что канал latest обновляется непрерывно, поэтому отставание на несколько коммитов — это фактически нормальное состояние покоя, но страница воспринимает это как ошибку. Поэтому вместо переработки всей системы я бы сосредоточился на том, чтобы различать сигнал и шум.
Как я это вижу, на странице есть один статус-баннер, значение которого меняется в зависимости от вашего текущего положения:
latest на несколько коммитов → серый/информационный, с явной пометкой действие не требуется. Это то состояние, которое сейчас кричит, но на самом деле не должно.v2026.8.0) → заметный, со ссылкой на примечания к выпуску.Только последние два должны создавать ощущение необходимости предпринять какие-либо действия.
Несколько других вещей, которые я бы хотел видеть там:
v2026.8.0-latest.1 · dfe770d · latest). Это самая частая жалоба, которую я видел, и её легко вернуть.По компонентам и пересборке: главное, что я хотел бы сделать явным, — это разделение между обновлениями, которые веб-обновщик может применить самостоятельно (ядро + плагины, через git pull), и теми, которые меняют контейнер и поэтому требуют выполнения ./launcher rebuild app из командной строки. Список компонентов, где каждая строка показывает, к какой категории он относится, очень бы помог, а для случая пересборки можно было бы показывать точную команду с кнопкой копирования, вместо того чтобы заставлять пользователей гадать.
По совместимости плагинов: механизм .discourse-compatibility уже обрабатывает случай, когда ваше ядро старее, чем то, на которое сейчас ориентирован плагин: он тихо выбирает последний совместимый коммит этого плагина во время пересборки. Это в основном влияет на стабильные/ESR-установки, и сегодня это происходит незаметно. Было бы здорово выводить это как простую информационную строку «удерживается на совместимой версии», чтобы администраторы старых релизов могли видеть, почему плагин не на последнем коммите. (Обратный случай, когда плагин ещё не поддерживает новое ядро, сегодня не обрабатывается; есть открытый запрос на функцию минимальных/максимальных совместимых версий, который бы это покрыл.)
Я быстро собрал интерактивный макет, чтобы посмотреть, как разные состояния выглядят рядом — честно говоря, главная победа здесь — это просто состояние «вы отстаёте, но это нормально». Как только это перестанет быть сигналом тревоги, страница снова станет по-настоящему полезной. С удовольствием поделюсь макетом, если кому-то захочется его потрогать.
Отличная идея.
Только одно уточнение по этому моменту:
Я думаю, речь будет идти об обновлениях, которые вы сами установили, а не обязательно о «выпусках», которые мы делаем.
То есть каждый раз, когда вы выполняете обновление, появляется новая строка. Она может соответствовать 5 коммитам в рамках одного выпуска. Или, например, переходу с версии 2026.1.6 на 2026.7.1, если вы ждали первого патч-релиза после выхода следующего ESR, чтобы обновиться.
В любом случае, это должна быть история обновлений, которые вы ранее выполнили на вашем сайте, и набор изменений между ними.
Добавьте заметное предупреждение о важности создания резервной копии перед началом!
Упомяните, что в случае сбоя обновления следующим шагом будет пересборка лаунчера через командную строку. Хотя бы примечание о том, что обновления иногда завершаются неудачей, что приводит к недоступности форума.
В идеале — механизм сигнализации о том, что ожидаемые изменения включают нечто существенное, например, повышение версии базы данных, которое произошло недавно и которое, насколько я помню, в прошлый раз стало по-настоящему значительным событием, судя по количеству тем, созданных здесь для получения поддержки.
Ах, это действительно лучшая формулировка, чем моя, в этом ты прав. Я представлял себе список твоих релизов, но журнал обновлений, которые этот сайт действительно внедрил, будет полезнее.
Таким образом, каждая строка представляет событие обновления и показывает переход с → на и какое набор изменений был между ними. Это, конечно, покрывает оба случая: небольшое повышение версии внутри канала с несколькими коммитами или большой скачок, как v2026.1.6 → v2026.7.1, если кто-то на ESR ждал первого патча после выпуска следующей версии ESR.
