Discourse не выпускает LTS-версии

Я не был осведомлен о совместимости с Discourse, так что это то, что мне нужно будет изучить.

Я хочу затронуть этот вопрос, потому что, похоже, существует огромный разрыв между тем, как команда Discourse воспринимает стабильную ветку, и тем, как сообщество Discourse и более широкая аудитория администраторов форумов воспринимают стабильное предложение Discourse.

Ключевые причины, по которым стабильная ветка не соответствует определению LTS.

1) Персонал активно отговаривает от использования стабильной ветки, когда речь заходит о ней

Я не обязательно хочу указывать на конкретных участников, но вот подборка постов от сотрудников, иллюстрирующая эту тенденцию:

Обратите внимание, что в некотором смысле tests-passed более стабилен, чем stable, так как именно его использует discourse.org, поэтому он лучше всего протестирован.

Таким образом, Discourse находится в состоянии перманентной беты, что означает, что мы постоянно работаем над новыми функциями и улучшениями. В нашем случае бета не означает нестабильность; мы хостим сайты с миллионами ежемесячных просмотров страниц на наших версиях tests-passed и beta.

Канал stable не обязательно более «стабилен», чем tests-passed. Речь скорее о том, что ошибки известны, и он служит контрольной точкой для определенного набора функций и улучшений. В случае с tests-passed могут появляться новые ошибки, которые затем исправляются через несколько коммитов.

Послание было довольно последовательным: Discourse находится в состоянии «перманентной беты», что не соответствует ожиданиям пользователей production / не-разработчиков.

При быстром поиске в DuckDuckGo по запросу «discourse stable» ни одна из десяти лучших ссылок не выглядит так, будто она рекомендует использовать stable. Таким образом, независимо от его фактического качества, если персонал повсеместно отговаривает от использования stable, это создает у людей негативное впечатление о его пригодности для решения задач.

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

2. LTS получает исправления ошибок, выходящие за рамки только исправлений ошибок безопасности

LTS — это то, что не получает обновлений функций, но получает исправления ошибок. Согласно собственным комментариям персонала, в Discourse, похоже, не прилагается усилий по переносу исправлений ошибок для несекьюритных проблем. Возможно, это не так, но именно это нам говорили.

3. У LTS есть понятные шаги установки

Руководство по установке даже не упоминает существование stable.

4. LTS широко используется

До вашего поста я не слышал о широком использовании стабильной ветки. Используется ли она широко в реальной жизни? Учитывая, насколько она скрыта, я сомневаюсь, но у меня нет никаких метрик, чтобы это подтвердить. Это важный фактор, так как он дает людям уверенность в использовании stable для своих production-развертываний.

5. У LTS есть четкий цикл выпуска и заметки об обновлении

Я не вижу никакого центрального места, где stable была бы четко задокументирована. (Возможно, я просто что-то упустил!)

Мои ожидания от LTS — это страница, которая описывает:

  • Текущую активную версию выпуска
  • Заметки о выпуске, включая:
    • Основные изменения/функции между версиями LTS
    • Шаги миграции с предыдущего выпуска LTS (особенно важные изменения, о которых нужно знать)
  • Планируемая продолжительность активной поддержки для каждой версии

пример: mediawiki, но на самом деле любой крупный открытый проект с LTS имеет подобные страницы.

Эта документация помогает мне планировать действия на случай, когда произойдет критическое изменение, требующее простоя и/или ручного вмешательства.

6. В рамках одного цикла выпуска LTS не должно быть критических изменений, ломающих совместимость

Возможно, это так для stable, но я слишком привык нажимать кнопку обновления, после чего форум перестает работать, чтобы быть уверенным в этом. Думаю, что я ищу здесь более четкие предупреждения при переходе между версиями, которые ломают что-то.

7. LTS предоставляет предупреждения об устаревании API как минимум на протяжении одного полного цикла LTS

Это должно измеряться в масштабе года+, а не месяца+.

8. У LTS есть запланированные периоды поддержки с перекрытием

Любой крупный LTS имеет период перекрытия поддержки между двумя версиями LTS. Stable, похоже, просто делает бинарный переход к следующей версии. (Мое впечатление может также быть ошибочным из-за отсутствия центральной страницы документации)

9. Переход с не-LTS на LTS должен быть простым

Нет необходимости поддерживать обратный переход, но когда доступна LTS, неясно, как чисто переключить ветку на LTS. Похоже, что в форуме есть несколько постов об этом, но, опять же, я не нашел никакой централизованной документации.


Я поклонник Discourse, но это общая болевая точка, с которой сталкиваюсь я и многие другие люди. То, что stable представляет собой сейчас, — это просто ветка, а не LTS.

4 лайка

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

4 лайка

Если мы сравним грустное лицо в панели администратора с большим отставанием в количестве коммитов в разделе «Обновить Discourse»:

является ли критическое обновление частью tests-passed? И если вы нажмёте «Обновить всё» сразу же после смены статуса с «счастливого» на «грустный» лицо, то вы синхронизируетесь с tests-passed?

По-моему, это обновление требует пересборки из консоли. Дважды.

1 лайк

Похоже, что Discourse отличается высокой скоростью изменений и амбициозным планом развития.

Для поддержки этого процесса требуется много обратной связи от пользователей. Мне кажется, что здесь явно прослеживается стратегия продвижения ветки tests-passed, поскольку она обеспечивает раннюю обратную связь по новым изменениям.

Взамен пользователь получает бесплатное программное обеспечение и новые функции. Это своего рода договор. Мне кажется, что со временем эта сделка доказала свою эффективность.

Стабильная сборка не так сильно помогает в разработке, поэтому, возможно, её продвижение не так выгодно с точки зрения бизнеса (это лишь моё мнение, я не представляю CDCK).

Другая проблема со стабильной версией заключается в следующем, и она ещё более значима:

Обычно между стабильными версиями происходит множество изменений, включая существенные устаревания и изменения API. Участие в ветке tests-passed в качестве разработчика, администратора сайта или создателя темы даёт возможность решать изменения небольшими порциями, вместо того чтобы каждый раз при достижении следующей стабильной версии сталкиваться с огромной горой задач.

Для поддержки таких больших скачков, вероятно, потребуется тестовый сервер и набор тестовых сценариев для проверки.

Если вы не владеете никакими собственными кастомизациями, вы можете выбрать стабильную версию, но в этом случае вы сильно полагаетесь на других, на которых у вас может не быть существенного влияния, чтобы убедиться, что используемые вами дополнения достаточно поддерживаются для вашего следующего обновления. Возможно, вы обнаружите, что к моменту обновления некоторые элементы потеряют поддержку, и тогда вы можете оказаться в сложном положении. Также может оказаться, что разработчик вообще не поддерживает стабильную версию, и вам придётся форкнуть проект и подготовить «вырезанную» версию плагина для поддержки вашей стабильной сборки. (Однако, существует хорошая система привязки версий, так что это не требует огромных усилий)

Другим важным аспектом Discourse является то, что он очень интенсивно использует модульные тесты, поэтому ветка tests-passed обычно отличается высокой стабильностью.

5 лайков

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

Я считаю, что более реалистичная причина, по которой они не поддерживают полноценный LTS, заключается в том, что это потребовало бы от кого-то в команде времени на управление и документирование этого. Это функция, которая в первую очередь приносит пользу тем, кто размещает систему самостоятельно, поэтому, полагаю, они рассматривают её как пустую трату времени. Однако это своего рода ожидаемая функция, и её отсутствие является реальным недостатком, когда администраторы форумов выбирают программное обеспечение для своих форумов, поскольку другие современные аналоги предлагают более стабильные решения.

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

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