The reality here is that the stable branch is an LTS, and a pretty good one as well. It receives security updates and it’s pretty clear which plugin versions are compatible with it (thanks to the .discourse-compatibility file). I will totally admit that it took a long time before this all started working out, but in the past two years or so, it has - which is a great accomplishment by the team.
Now for the second part of your statement. It’s indeed the case that stable is often represented as something you shouldn’t want. But on Communiteq hosting, we have been giving clients the free choice between stable (“stability first, new updates twice per year, security updates once per month”) and tests-passed (“always on the edge, new features once per month”) for the past 2.5 years and 85% chooses to be on stable.
I get that. But isn’t that a dev issue and not a production issue? I can totally understand that you’re doing this in dev. But adding those plugins in a default production install kind of defeats the idea of having a plugin (which is something not-default by definition).
The only actual production benefit that I see is the very, very edge issue of uninstalling plugins and multisite hosts. (Again, this is a good thing, all other production issues have been resolved over time!)
That could have also been resolved in the setup script by showing a list of plugins that users can check and then adding them to app.yml
But you’re still offering different (sub)sets of plugins for different tiers, right?