Круто, спасибо за объяснение.
Итак, я налил себе 
и попробовал это с помощью плагина Custom Wizard.
Я проверил каждый тег по одному в обратном порядке, начиная с v2.6.0.beta1. Эти команды git оказались полезными:
git tag --list \\ например, git tag --list 'v2.5.0*'
git checkout tags/tag \\ например, git checkout tags/v2.5.0.beta7
Недолго пришлось искать тег, который не работал с текущей версией плагина: в v2.5.0.beta7 отсутствует discourse/app/components/d-textarea, который пытается импортировать кастомный мастер.
Таким образом, я нашел коммит в плагине, где был добавлен этот импорт, взял sha1 предыдущего коммита, переключился на него и протестировал (все работало отлично), а затем добавил это в .discourse-compatibility:
v2.5.0.beta7: 802d74bab2ebe19a106f75275342dc2e9cc6066a
Затем я отправил это в ветку с последним кодом плагина (ветка для тестирования, обычно не обязательная), и собрал заново тестовый сервер в контейнере Docker с этой веткой плагина и параметром version, установленным в v2.5.0.beta7.
Это не сработало, и тут меня осенило, что, конечно, задача rake plugin:pull_compatible_all не существует в v2.5.0.beta1, поэтому это не сработает ретроспективно (виноват ). И действительно, в логах запуска я вижу:
Неизвестно, как выполнить задачу 'plugin:pull_compatible_all' (см. список доступных задач с помощью `rake --tasks`)
Но это ли суть того, как вы представляете использование этого механизма?
Что касается required_version, я столкнулся с этим здесь, так как на тестовом сервере был установлен плагин discourse-legal-tools, у которого required_version равен v2.5.0, поэтому изначально он не работал с v2.5.0.beta7. Думаю, я перенесу этот плагин на новую систему. Я все еще вижу, что required_version может быть полезен для установки абсолютного базового уровня, как вы и говорили.