Estou me perguntando se podemos dar aos plugins um número de versão para permitir que a lista de plugins tenha a versão mínima e máxima com a qual é compatível.
Assim, não corremos o risco de o nosso plugin ser atualizado, mas a nossa versão do discourse ficar para trás e, em seguida, quebrar todo o site.
Existem duas classes amplas de plugins e TC’s:
Plugins oficiais já mantêm a compatibilidade e, se não forem compatíveis, geralmente há um desenvolvedor assalariado corrigindo as coisas em poucos dias.
Já é difícil o suficiente para os mantenedores manterem as coisas compatíveis, quanto mais acompanhar se elas são ou não.
Existem apenas duas versões que são práticas para manter:
stable mais recentetests-passed mais recenteVocê já pode usar o sistema de fixação (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) para fixar o stable. Pode ser muito bom exibir isso de alguma forma para mostrar compatibilidade explícita, mas não significa que o plugin não seja compatível se não houver uma fixação.
A compatibilidade com o mais recente pode ser exibida com um visto verde do CI no GitHub.
Isso depende de duas coisas:
O último é um grande pedido para mantenedores de terceiros que fazem as coisas de graça.
Para plugins não oficiais, sua solicitação de recurso se resume a um financiamento decente de plugins de terceiros.
Como um autor experiente de plugins que já passou por isso, posso dizer que é quase impossível financiar plugins de terceiros.
A única razão pela qual meus plugins ainda funcionam é porque:
Isso é valioso para mim, mas tem seus limites.
Eu diria que o desenvolvimento de plugins de terceiros está perto de 
no ecossistema Discourse, com apenas um punhado muito pequeno de desenvolvedores capazes de manter as coisas funcionando contra a velocidade muito exigente do núcleo.
Outras exceções:
Dado que você só pode realmente confiar em plugins oficiais sendo compatíveis (e talvez um punhado adicional de desenvolvedores muito ativos como eu ou Communiteq), sugiro que você simplesmente se concentre em usar os plugins #oficiais e, para esses, acho que sua solicitação de recurso é redundante porque um processo está em vigor para que essas coisas acompanhem o núcleo.
Não tenho certeza de como definiria uma versão máxima compatível para um plugin. Um plugin simples provavelmente poderia dizer que funciona até pelo menos 4.0, e quando 4.0 chegar, ele ainda pode funcionar porque o CDCK não introduziu nenhuma alteração que quebre a compatibilidade.
Mas talvez o plugin simples usasse algo que o CDCK descontinuou na versão 3.8 e removeu na 3.10… Bastante difícil levar isso em consideração.
Porque você não pode.
Ficará desatualizado assim que o próximo commit for lançado.
Mas é simples:
Em seguida, verifique o visto verde antes de instalar.
Tenho brincado com isso e cheguei a uma solução no Github.
Portanto, apenas um tique verde para o trabalho de CI mais recente não é suficiente, pois as coisas podem ter mudado recentemente, o que pode quebrar o plugin. Basicamente, você precisa executar novamente os trabalhos de CI quando o Discourse atualizar os branches.
Neste repositório de exemplo, desenvolvi uma solução eficiente. É basicamente um workflow agendado que verifica os branches importantes do repositório Discourse para ver se há alterações; se houver, ele acionará o workflow normal de CI, que deve executar a suíte de testes. Em seu readme, você pode então colocar alguns badges para mostrar como os workflows de CI foram executados contra as alterações mais recentes.
O workflow de monitoramento é executado em segundos. Portanto, quando agendado, ele consumiria apenas 1 minuto de tempo de ação do Github.
Obviamente, a confiabilidade de toda essa configuração depende do esforço do desenvolvedor do plugin/componente de tema na criação de uma boa suíte de testes.
E você ainda tem o problema de UX de que, na página de “atualização” do Discourse, você não sabe se o trabalho de CI mais recente falhou para uma versão específica.
Portanto, além de ter um workflow de monitoramento que reconstrói um plugin quando o branch do Discourse muda, você precisa criar um artefato de build registrando o resultado (passa/falha). Em seus metadados de plugin, você deve ser capaz de apontar para este artefato, e o Discourse deve recuperar este artefato para exibir a compatibilidade/resultado na interface de atualização.
Não é uma construção à prova de falhas, mas é alguma coisa.
É por isso que escrevi “em cada novo commit do core no CI” 
Tivemos um dashboard no Pavilion por muito tempo que fazia exatamente tudo isso.