Je me demande si nous pouvons donner un numéro de version aux plugins pour permettre à la liste des plugins d’indiquer la version minimale et maximale avec laquelle il est compatible.
Ainsi, nous ne nous retrouverons pas dans la situation où notre plugin est mis à jour, mais notre version de discourse est en retard et cela casse tout le site.
Il existe deux grandes catégories de plugins et de TC :
Les plugins officiels sont déjà compatibles, et s’ils ne le sont pas, un développeur salarié corrige généralement les problèmes en quelques jours.
Il est déjà suffisamment difficile pour les mainteneurs de maintenir la compatibilité, sans parler de savoir s’ils le font ou non.
Il n’y a en réalité que deux versions qui sont pratiques à maintenir :
stabletests-passedVous pouvez déjà utiliser le système d’épinglage (Pinning plugin and theme versions for older Discourse installs (.discourse-compatibility)) pour épingler la version stable. Il serait intéressant de le mettre en évidence d’une manière ou d’une autre pour montrer une compatibilité explicite, mais cela ne signifie pas que le plugin n’est pas compatible s’il n’y a pas d’épinglage.
La compatibilité avec la dernière version pourrait être signalée par une coche verte de CI sur GitHub.
Cela repose sur deux choses :
Ce dernier point est une demande importante pour les mainteneurs tiers qui font les choses gratuitement.
Pour les plugins non officiels, votre demande de fonctionnalité se résume à un financement décent des plugins tiers.
En tant qu’auteur de plugins expérimenté qui a beaucoup d’expérience, je peux vous dire qu’il est presque impossible de financer des plugins tiers.
La seule raison pour laquelle mes plugins fonctionnent encore est que :
C’est précieux pour moi, mais cela a ses limites.
Je dirais que le développement de plugins tiers est proche de 
dans l’écosystème Discourse, avec seulement une très petite poignée de développeurs capables de maintenir les choses à jour face à la vélocité très exigeante du cœur de Discourse.
Autres exceptions :
Étant donné que vous ne pouvez vraiment compter que sur la compatibilité des plugins officiels (et peut-être une poignée d’autres de développeurs très actifs comme moi ou Communiteq), je vous suggère de vous concentrer simplement sur l’utilisation des plugins #officiels et pour ceux-ci, je pense que votre demande de fonctionnalité est redondante car un processus est en place pour qu’ils suivent le cœur de Discourse.
Je ne suis pas sûr de la manière dont je pourrais définir une version maximale compatible pour un plugin. Un plugin simple pourrait probablement dire qu’il fonctionne au moins jusqu’à la version 4.0, et lorsque la version 4.0 arrivera, il pourrait toujours fonctionner car CDCK n’aura pas introduit de changements majeurs.
Mais peut-être que le plugin simple utilisait quelque chose que CDCK a déprécié dans la version 3.8 et supprimé dans la version 3.10… C’est assez difficile à prendre en compte.
Parce que vous ne le pouvez pas.
Il sera obsolète dès que le prochain commit sera publié.
Mais c’est simple :
Vérifiez ensuite la coche verte avant d’installer.
J’ai joué avec ça et j’ai trouvé une solution sur Github.
Donc, juste un coche vert pour le travail CI le plus récent ne suffit pas, car les choses pourraient avoir changé récemment, ce qui pourrait casser le plugin. Essentiellement, vous devez réexécuter les travaux CI lorsque Discourse met à jour les branches.
Dans cet exemple de dépôt, j’ai trouvé une solution efficace. Il s’agit essentiellement d’un workflow planifié qui vérifie les branches importantes du dépôt Discourse pour voir s’il y a des changements, s’il y en a, il déclenchera le workflow CI normal qui devrait exécuter la suite de tests. Dans votre readme, vous pouvez alors placer des badges pour montrer comment les workflows CI ont fonctionné par rapport aux changements les plus récents.
Le workflow de surveillance s’exécute en quelques secondes. Ainsi, lorsqu’il est planifié, il ne consommerait qu’une minute de temps d’action Github.
Évidemment, la fiabilité de toute cette configuration dépend de l’effort du développeur du plugin/composant de thème pour créer une bonne suite de tests.
Et vous avez toujours le problème d’UX selon lequel, depuis la page “mise à jour” de Discourse, vous ne savez pas si le travail CI le plus récent a échoué pour une version spécifique.
Donc, en plus d’avoir un workflow de surveillance qui reconstruit un plugin lorsque la branche Discourse change, vous devez créer un artefact de build enregistrant le résultat (réussite/échec). Dans les métadonnées de votre plugin, vous devriez être en mesure de pointer vers cet artefact, et Discourse devrait récupérer cet artefact pour afficher la compatibilité/le résultat dans l’interface de mise à jour.
Ce n’est pas une construction infaillible, mais c’est quelque chose.
C’est pour ça que j’ai écrit “à chaque nouveau commit du cœur dans CI” 
Nous avons eu un tableau de bord sur Pavilion pendant longtemps qui faisait exactement tout cela.