[keycloak-dev] Some branches are gone?
sthorger at redhat.com
Fri Sep 9 14:26:38 EDT 2016
We fully understand where you are coming from, but we simply don't have
enough resources to backport fixes to older branches.
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.
On 9 September 2016 at 17:35, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:
> 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
> 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.
> https://github.com/spring-projects/spring-boot/tree/master/.github (raw
> 2016-09-09 14:33 GMT+02:00 Bill Burke <bburke at 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
>> >> 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the keycloak-dev