Cool, merci pour ces explications.
Alors, je me suis servi un 
et j’ai essayé avec le plugin Custom Wizard.
J’ai vérifié chaque tag un par un, dans l’ordre inverse, en commençant par v2.6.0.beta1. Ces commandes git m’ont été utiles :
git tag --list \\ par exemple git tag --list 'v2.5.0*'
git checkout tags/tag \\ par exemple git checkout tags/v2.5.0.beta7
Ça n’a pas pris trop de temps pour trouver un tag qui ne fonctionnait pas avec la version actuelle du plugin : v2.5.0.beta7 n’inclut pas discourse/app/components/d-textarea, que le wizard personnalisé tente d’importer.
Ensuite, j’ai trouvé le commit dans le plugin qui a ajouté cet import, j’ai récupéré le sha1 du commit précédent, je l’ai appliqué, j’ai testé (ça a fonctionné), et j’ai ajouté ceci à .discourse-compatibility :
v2.5.0.beta7: 802d74bab2ebe19a106f75275342dc2e9cc6066a
J’ai ensuite poussé cela sur une branche avec le code le plus récent du plugin (une branche de test, pas nécessaire normalement), et j’ai reconstruit un serveur de test dockerisé avec cette branche du plugin et la version définie sur v2.5.0.beta7.
Ça n’a pas fonctionné, puis il m’est venu à l’esprit que, bien sûr, la tâche rake plugin:pull_compatible_all n’existe pas dans v2.5.0.beta1, donc cela ne peut pas fonctionner rétrospectivement (je blâme le ). Effectivement, dans les journaux du launcher, je vois :
Don't know how to build task 'plugin:pull_compatible_all' (See the list of available tasks with `rake --tasks`)
Est-ce que c’est bien l’essentiel de la façon dont tu imagines que cela devrait être utilisé ?
Concernant le champ required_version, je l’ai rencontré ici car le serveur de test avait le plugin discourse-legal-tools installé, qui a un required_version de v2.5.0, donc il a échoué initialement sur v2.5.0.beta7. Je pense que je vais transférer ce plugin vers ce nouveau système. Je vois toujours l’utilité de required_version pour définir une base absolue, comme tu le dis.