<div dir="ltr">We fully understand where you are coming from, but we simply don't have enough resources to backport fixes to older branches.<div><br></div><div>This level of maintenance is available in the supported version of Keycloak. If you need to stay on a version for a longer period of time, receive backported fixes and security patches as well as a higher level of support that's what it's there for. I would highly recommend anyone that uses Keycloak in production to consider using the supported product.<br><div class="gmail_extra"><br><div class="gmail_quote">On 9 September 2016 at 17:35, Thomas Darimont <span dir="ltr"><<a href="mailto:thomas.darimont@googlemail.com" target="_blank">thomas.darimont@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello Bill, </div><div><br></div>Thanks for clarification.<div><br></div><div>Using a tagged version as the base for a fork is not very practical, since one now needs to investigate </div><div>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.</div><div><br></div><div>I understand that it is very laborious to maintain a lot of maintenance branches but I think retaining a few <br></div><div>intermediate branches wouldn't hurt too much. Sometimes it's just about doing a git cherry-pick on a commit</div><div>or massging a commit a little bit to make it applicable to an earlier version.</div><div>This model is quite common for other projects e.g. the Spring Ecosystem.</div><div><br></div><div>Retiring old branches branches (e.g. <= 1.9) is IMHO fine but as said - the Keycloak team </div><div>should IMHO really reconsider your maintenance policy.</div><div><br></div><div>Why base a fork on an earlier version? Well sometimes one needs to apply functionality or security patches </div><div>or integrate new features that are tested but not yet released in the form of an official release by the Keycloak project.</div><div><br></div><div>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) </div><div>version is quite high.</div><div><br></div><div><div>As <span style="font-size:12.8px">Juraci suggested, </span>one could use github commit templates to ensure that PR's are sent against the master branch.</div><div>See: </div><div><a href="https://github.com/spring-projects/spring-boot/tree/master/.github" target="_blank">https://github.com/spring-<wbr>projects/spring-boot/tree/<wbr>master/.github</a> (raw format)<br></div><div><a href="https://github.com/blog/2111-issue-and-pull-request-templates" target="_blank">https://github.com/blog/2111-<wbr>issue-and-pull-request-<wbr>templates</a><br></div></div><div><br></div><div>Cheers,<br></div><div>Thomas</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-09-09 14:33 GMT+02:00 Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We won't be reviewing or accepting PRs to anything but master and maybe<br>
1.9.x. We just don't have the cycles to maintain older versions. We<br>
strive to maintain backward compatibility whenever possible. WE try to<br>
make keycloak upgradable and will make fixes around this accordingly.<br>
We have said this from day one. Releases are tagged, so if you need to<br>
stay on a specific version for whatever reason, then you can branch and<br>
maintain the branch yourselves. I don't recommend this though as you<br>
will get no help from us and you'll be on your own. If stability is<br>
something you strive for, then I suggest you work off the community<br>
version our product is based on: 1.9.x.<br>
<br>
<br>
On 9/9/16 8:24 AM, Juraci Paixão Kröhling wrote:<br>
<span>> On 09/09/2016 02:17 PM, Stian Thorgersen wrote:<br>
>> With a new minor release of Keycloak every 6 weeks that ends up being a<br>
>> lot of dead branches to keep around. Removing them makes it clear they<br>
>> are no longer maintained and stops people from sending PRs to them (this<br>
>> regularly happens).<br>
</span>> How about adding a CONTRIBUTING.md , telling people to send PRs only to<br>
> the branches you'd review/accept? If there's a CONTRIBUTING.md file,<br>
> GitHub will add a link to it on the "Submit PR" page.<br>
><br>
> - Juca.<br>
<div><div>> ______________________________<wbr>_________________<br>
> keycloak-dev mailing list<br>
> <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/keycloak-dev</a><br>
<br>
______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div></div></div>