Re: [keycloak-dev] Some branches are gone?

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: https://github.com/spring-projects/spring-boot/tree/master/.github (raw format) https://github.com/blog/2111-issue-and-pull-request-templates Cheers, Thomas 2016-09-09 14:33 GMT+02:00 Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>>: We won't be reviewing or accepting PRs to anything but master and maybe 1.9.x. We just don't have the cycles to maintain older versions. We strive to maintain backward compatibility whenever possible. WE try to make keycloak upgradable and will make fixes around this accordingly. We have said this from day one. Releases are tagged, so if you need to stay on a specific version for whatever reason, then you can branch and maintain the branch yourselves. I don't recommend this though as you will get no help from us and you'll be on your own. If stability is something you strive for, then I suggest you work off the community version our product is based on: 1.9.x. On 9/9/16 8:24 AM, Juraci Paixão Kröhling wrote: > On 09/09/2016 02:17 PM, Stian Thorgersen wrote: >> With a new minor release of Keycloak every 6 weeks that ends up being a >> lot of dead branches to keep around. Removing them makes it clear they >> are no longer maintained and stops people from sending PRs to them (this >> regularly happens). > How about adding a CONTRIBUTING.md , telling people to send PRs only to > the branches you'd review/accept? If there's a CONTRIBUTING.md file, > GitHub will add a link to it on the "Submit PR" page. > > - Juca. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>