Me pregunto si podemos dar a los plugins un número de versión para permitir que la lista de plugins especifique la versión mínima y máxima de Discourse con la que es compatible.
Así no nos encontramos en la situación en la que nuestro plugin se actualiza, pero nuestra versión de Discourse se queda atrás y luego rompe todo el sitio.
Hay dos clases generales de plugins y TC:
Los plugins oficiales ya mantienen la compatibilidad, y si no son compatibles, normalmente hay un desarrollador asalariado que soluciona las cosas en cuestión de días.
Ya es bastante difícil para los mantenedores mantener la compatibilidad, y mucho menos saber si lo es o no.
Solo hay dos versiones que son prácticas de mantener:
stable más recientetests-passed más recienteYa puedes usar el sistema de fijación (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) para fijar la versión stable. Podría ser muy útil mostrar eso de alguna manera para indicar compatibilidad explícita, pero no significa que el plugin no sea compatible si no hay una fijación.
La compatibilidad con la última versión podría mostrarse con una marca verde de CI en GitHub.
Eso depende de dos cosas:
Esto último es mucho pedir para los mantenedores de terceros que hacen las cosas gratis.
Para los plugins no oficiales, tu solicitud de funciones se reduce a una financiación decente de los plugins de terceros.
Como autor experimentado de plugins que ha pasado por mucho, puedo decirte que es casi imposible financiar plugins de terceros.
La única razón por la que mis plugins siguen funcionando es porque:
Eso es valioso para mí, pero tiene sus límites.
Diría que el desarrollo de plugins de terceros está cerca de 
en el ecosistema de Discourse, con solo un puñado muy pequeño de desarrolladores capaces de mantener las cosas funcionando ante la exigente velocidad del núcleo.
Otras excepciones:
Dado que solo puedes confiar realmente en que los plugins oficiales sean compatibles (y quizás en un puñado adicional de desarrolladores muy activos como yo o Communiteq), te sugiero que simplemente te centres en usar los plugins official y para esos, creo que tu solicitud de funciones es redundante porque existe un proceso establecido para que esas cosas hagan un seguimiento del núcleo.
No estoy seguro de cómo podría definir una versión máxima compatible para un plugin. Un plugin simple probablemente podría decir que funciona hasta al menos la versión 4.0, y cuando llegue la versión 4.0, podría seguir funcionando porque CDCK no introdujo ningún cambio que rompa la compatibilidad.
Pero tal vez el plugin simple utilizó algo que CDCK marcó como obsoleto en la versión 3.8 y eliminó en la versión 3.10… Es bastante difícil tener esto en cuenta.
Porque no puedes.
Estará desactualizado tan pronto como se publique el próximo commit.
Pero es simple:
Luego, comprueba si hay una marca verde antes de instalar.
He estado jugando con esto y he encontrado una solución en Github.
Así que una simple marca verde para el trabajo de CI más reciente no es suficiente, ya que las cosas podrían haber cambiado recientemente, lo que podría romper el plugin. Básicamente, necesitas volver a ejecutar los trabajos de CI cuando Discourse actualiza las ramas.
En este repositorio de ejemplo desarrollé una solución eficiente. Es básicamente un flujo de trabajo programado que comprueba las ramas importantes del repositorio de Discourse para ver si hay cambios; si los hay, activará el flujo de trabajo normal de CI que debería ejecutar la suite de pruebas. En tu readme, puedes colocar algunas insignias para mostrar cómo se ejecutaron los flujos de trabajo de CI contra los cambios más recientes.
El flujo de trabajo de monitoreo se ejecuta en segundos. Por lo tanto, cuando se programa, solo consumiría 1 minuto de tiempo de acción de Github.
Obviamente, la fiabilidad de toda esta configuración depende del esfuerzo del desarrollador del plugin/componente temático para crear una buena suite de pruebas.
Y todavía tienes el problema de la experiencia de usuario de que, desde la página de “actualización” de Discourse, no sabes si el trabajo de CI más reciente falló para una versión específica.
Por lo tanto, además de tener un flujo de trabajo de monitoreo que reconstruye un plugin cuando la rama de Discourse cambia, necesitas crear un artefacto de compilación que registre el resultado (éxito/fallo). En los metadatos de tu plugin, deberías poder apuntar a este artefacto, y Discourse debería recuperar este artefacto para mostrar la compatibilidad/resultado en la interfaz de actualización.
No es una construcción infalible, pero es algo.
por eso escribí “en cada nuevo commit del núcleo en CI” 
tuvimos un panel en Pavilion durante mucho tiempo que hizo exactamente todo esto.