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@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 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: 

Cheers,
Thomas

2016-09-09 14:33 GMT+02:00 Bill Burke <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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev