Мне интересно, можем ли мы присвоить плагинам номер версии, чтобы в списке плагинов указывались минимальная и максимальная версии Discourse, с которыми они совместимы.
Так мы избежим ситуации, когда плагин обновился, а версия Discourse осталась устаревшей, и это сломает весь сайт.
Существует два основных класса плагинов и тем для TC:
Официальные плагины уже поддерживают совместимость, и если она нарушается, обычно оплачиваемый разработчик исправляет проблемы в течение нескольких дней.
Майнтейнерам и так трудно поддерживать совместимость, не говоря уже о том, чтобы отслеживать, сохраняется ли она.
На практике имеет смысл поддерживать совместимость только с двумя версиями:
stable)tests-passed)Вы уже можете использовать систему привязки версий (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)), чтобы зафиксировать версию для stable. Было бы неплохо каким-то образом явно отображать эту информацию, чтобы показать совместимость, но отсутствие привязки не означает, что плагин не совместим.
Совместимость с последней версией может отображаться зелёной галочкой от CI на GitHub.
Это зависит от двух вещей:
Последнее — большая просьба к сторонним майнтейнерам, работающим бесплатно.
Для неофициальных плагинов ваш запрос на новую функцию сводится к адекватному финансированию плагинов от сторонних разработчиков.
Как опытный автор плагинов, повидавший многое, могу сказать, что финансирование таких плагинов почти невозможно.
Единственная причина, по которой мои плагины всё ещё работают, заключается в следующем:
Это ценно для меня, но имеет свои пределы.
Скажу так: разработка плагинов от сторонних разработчиков в экосистеме Discourse близка к 
, и лишь очень немногие разработчики способны поддерживать их работоспособность в условиях очень высокой скорости разработки ядра.
Другие исключения:
Поскольку вы действительно можете полагаться только на совместимость официальных плагинов (и, возможно, нескольких дополнительных от очень активных разработчиков, таких как я или Communiteq), я предлагаю просто сосредоточиться на использовании плагинов из категории official. Для них, на мой взгляд, ваш запрос на новую функцию излишен, так как уже существует процесс отслеживания изменений в ядре для таких плагинов.
Я не уверен, как определить максимальную совместимую версию для плагина. Простой плагин, вероятно, может заявить, что он работает как минимум до версии 4.0, и когда выйдет версия 4.0, он всё ещё может работать, поскольку CDCK не внесла никаких разрушающих изменений.
Однако возможно, что этот простой плагин использовал что-то, что CDCK устарела в версии 3.8 и удалила в версии 3.10… Учесть это довольно сложно.
Потому что это невозможно.
Она устареет сразу после выхода следующего коммита.
Но всё просто:
Перед установкой проверяйте наличие зелёной галочки.
Я поэкспериментировал с этим и нашёл решение в GitHub.
Просто зелёной галочки для самой последней задачи CI недостаточно, так как за последнее время могли произойти изменения, которые могут нарушить работу плагина. По сути, вам нужно перезапускать задачи CI при обновлении веток Discourse.
В этом примере репозитория я разработал эффективное решение. По сути, это запланированный рабочий процесс, который проверяет важные ветки репозитория Discourse на наличие изменений. Если изменения обнаружены, запускается обычный рабочий процесс CI, который должен выполнить набор тестов. В вашем README вы можете разместить бейджи, чтобы показать, как работали рабочие процессы CI по отношению к последним изменениям.
Рабочий процесс мониторинга выполняется за секунды. Поэтому при планировании он потребляет всего одну минуту времени действий GitHub.
Очевидно, что надёжность всей этой конструкции зависит от усилий разработчика плагина/темы-компонента по созданию качественного набора тестов.
И у вас всё ещё остаётся проблема UX: на странице «Обновление» в Discourse вы не знаете, не провалилась ли самая последняя задача CI для конкретной версии.
Поэтому, помимо наличия рабочего процесса мониторинга, который пересобирает плагин при изменении ветки Discourse, вам нужно создавать артефакт сборки, фиксирующий результат (успех/неудача). В метаданных вашего плагина вы должны иметь возможность указать на этот артефакт, и Discourse должен извлекать его, чтобы отображать информацию о совместимости/результате в интерфейсе обновлений.
Это не безупречная конструкция, но это уже что-то.
Вот почему я написал «при каждом новом коммите ядра в CI» 
У нас долгое время была панель управления в Pavilion, которая делала именно всё это.