<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>We maintain branches that our product is based on. I'm not
understanding why you can't create and maintain a branch yourself
based on a release tag. Git should be flexible enough to provide
the source management you require.<br>
</p>
<br>
<div class="moz-cite-prefix">On 9/9/16 11:35 AM, Thomas Darimont
wrote:<br>
</div>
<blockquote
cite="mid:CAK-7U1iimBnOnjZh3kKR0fr55X=isEQg_DjNeeKoreNE9d=0mg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
href="https://github.com/spring-projects/spring-boot/tree/master/.github">https://github.com/spring-projects/spring-boot/tree/master/.github</a>
(raw format)<br>
</div>
<div><a moz-do-not-send="true"
href="https://github.com/blog/2111-issue-and-pull-request-templates">https://github.com/blog/2111-issue-and-pull-request-templates</a><br>
</div>
</div>
<div><br>
</div>
<div>Cheers,<br>
</div>
<div>Thomas</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-09-09 14:33 GMT+02:00 Bill Burke <span
dir="ltr"><<a moz-do-not-send="true"
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 class="">> 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 class="HOEnZb">
<div class="h5">> ______________________________<wbr>_________________<br>
> keycloak-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br>
<br>
______________________________<wbr>_________________<br>
keycloak-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-dev"
rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/keycloak-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>