[keycloak-dev] Some branches are gone?

Thomas Darimont thomas.darimont at googlemail.com
Fri Sep 9 11:35:32 EDT 2016


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 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 (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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160909/8d15f41e/attachment.html 


More information about the keycloak-dev mailing list