Hello Bill,
Thanks for clarification.
Using a tagged version as the base for a fork is not very practical, since one now needs to investigate
every commit in master (or between two tags) whether or not they are compatible with the base version used for the fork - especially when a security fix needs to be applied quickly. That was actually the main idea behind the "let's base our fork on a recent maintenance branch" approach... once a new maintenance branch is created we'd upgrade to the latest maintenace branch version.
I understand that it is very laborious to maintain a lot of maintenance branches but I think retaining a few
intermediate branches wouldn't hurt too much. Sometimes it's just about doing a git cherry-pick on a commit
or massging a commit a little bit to make it applicable to an earlier version.
This model is quite common for other projects e.g. the Spring Ecosystem.
Retiring old branches branches (e.g. <= 1.9) is IMHO fine but as said - the Keycloak team
should IMHO really reconsider your maintenance policy.
Why base a fork on an earlier version? Well sometimes one needs to apply functionality or security patches
or integrate new features that are tested but not yet released in the form of an official release by the Keycloak project.
I strive for being as close as possible as to the latest released version because I assume that if security, stability or performance problems were found in older versions then the probability that they are corrected in a newer (potentially not yet released)
version is quite high.
As Juraci suggested, one could use github commit templates to ensure that PR's are sent against the master branch.
See:
Cheers,
Thomas