Cool, danke für die Erklärung.
Also habe ich mir ein 
eingeschenkt und es mit dem Custom Wizard Plugin ausprobiert.
Ich habe jedes Tag einzeln in umgekehrter Reihenfolge durchgegangen, beginnend mit v2.6.0.beta1. Diese Git-Befehle waren hilfreich:
git tag --list \\ z. B. git tag --list 'v2.5.0*'
git checkout tags/tag \\ z. B. git checkout tags/v2.5.0.beta7
Es hat nicht lange gedauert, bis ich ein Tag fand, das mit der aktuellen Version des Plugins nicht funktionierte: v2.5.0.beta7 enthält nicht discourse/app/components/d-textarea, das der benutzerdefinierte Assistent zu importieren versucht.
Daraufhin fand ich den Commit im Plugin, der diesen Import hinzugefügt hat, nahm die SHA1 des vorherigen Commits, checkte diesen aus und testete (funktionierte einwandfrei). Anschließend fügte ich Folgendes zu .discourse-compatibility hinzu:
v2.5.0.beta7: 802d74bab2ebe19a106f75275342dc2e9cc6066a
Danach habe ich das auf einen Branch mit dem neuesten Plugin-Code gepusht (ein Test-Branch, normalerweise nicht erforderlich), und einen Docker-Testserver mit diesem Plugin-Branch und der version auf v2.5.0.beta7 neu aufgebaut.
Das funktionierte nicht. Dann fiel mir ein, dass die Rake-Aufgabe plugin:pull_compatible_all natürlich in v2.5.0.beta1 noch nicht existiert, also wird das rückwirkend nicht funktionieren (ich gebe dem die Schuld). Tatsächlich sehe ich in den Launcher-Logs:
Don't know how to build task 'plugin:pull_compatible_all' (See the list of available tasks with `rake --tasks`)
Ist das im Großen und Ganzen das, wie du dir die Anwendung vorstellst?
Bezüglich required_version bin ich hier darauf gestoßen, da der Testserver das Plugin discourse-legal-tools installiert hatte, das eine required_version von v2.5.0 hat, weshalb es zunächst bei v2.5.0.beta7 fehlschlug. Ich denke, ich werde dieses Plugin in das neue System überführen. Ich kann mir trotzdem vorstellen, dass required_version nützlich ist, um, wie du sagst, eine absolute Basislinie festzulegen.