And I guess the maintainer/maintainers will retain the capability of skipping a scheduled recommended release if they feel like it's better not to (in case the current release having some serious regressions).
If the upcoming recommended release has a serious regression, then so would the version that the new players are downloading. The way to deal with regressions will be to immediately start rolling back code updates until the regression is removed. It's easy to restore those code updates, but the reaction will be to start rolling back as soon as any issue is discovered and then roll forward with a confirmed fix. Thereby, regressions should be resolved essentially immediately, not with fixes, but with rolling back. That buys time for doing a fix properly, avoids trying to patch broken code with potentially more broken code, and reduces how many other updates that go into the code base that could be broken themselves (it's a lot easier when something breaks if it's obviously the last thing that was merged, it's a lot more difficult when we are testing for the first time months after the fact and there are multiple things interacting with each to cause a breakage)
How about the recommended release being automatically skipped if there is one or more open GitHub issues with the "Regression" label on it?
That idea was floated, the regression label might become obsolete. It will depend how significant an issue is, but generally the response will be to remove all recent code updates until the culprit is removed.
(I obviously also assume the recommended release will not happen if it is the same as the previous one, like in case it is seasonal and no new version of TripleA was release in 3 or more months. Right?)
This is in part a rationale for 6 month cadence. Helps avoid that situation and reduces the frequency for players being asked to update