3:55 a.m.
Hello,
just found out that some of the maintenance branches: 2.1.x, 2.0.x are no
longer available in in the the keycloak github repository.
Only the 1.9.x & master branches are left :(
Did someone accidentally remove those branches?
Cheers,
Thomas
4:34 a.m.
They where deleted on purpose. 2.2 is about to be released, which means
there won't be any more 2.1 or 2.0 releases so these branches are no longer
needed.
On 9 September 2016 at 10:55, Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
Hello,
just found out that some of the maintenance branches: 2.1.x, 2.0.x are no
longer available in in the the keycloak github repository.
Only the 1.9.x & master branches are left :(
Did someone accidentally remove those branches?
Cheers,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
4:59 a.m.
Hello,
I think it would have been helpful to announce that on the keycloak-user
/-dev mailing-lists and Keycloak blog.
(In case it was announced - it was IMHO not stressed enough).
Some folks (including me) based their internal forks of Keycloak on top of
a "maintenance branch" like 2.1.x
expecting to be able to channel compatible fixes / patches into the said
custom fork.
With those maintenance branches now gone - this model no longer works.
Given that keycloak has now over 500 forks I guess that I'm not the only
one who followed that model.
I would suggest to keep some maintenace branches for previous versions
(e.g. 2.1.x) around to enable users
to upgrade their forks in a timely manner.
Cheers,
Thomas
2016-09-09 11:34 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
They where deleted on purpose. 2.2 is about to be released, which
means
there won't be any more 2.1 or 2.0 releases so these branches are no longer
needed.
On 9 September 2016 at 10:55, Thomas Darimont <thomas.darimont@googlemail.
com> wrote:
> Hello,
>
> just found out that some of the maintenance branches: 2.1.x, 2.0.x are no
> longer available in in the the keycloak github repository.
>
> Only the 1.9.x & master branches are left :(
>
> Did someone accidentally remove those branches?
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
7:17 a.m.
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).
Why not just base your branch of the Final tag?
On 9 September 2016 at 11:59, Thomas Darimont <
thomas.darimont(a)googlemail.com> wrote:
Hello,
I think it would have been helpful to announce that on the keycloak-user
/-dev mailing-lists and Keycloak blog.
(In case it was announced - it was IMHO not stressed enough).
Some folks (including me) based their internal forks of Keycloak on top of
a "maintenance branch" like 2.1.x
expecting to be able to channel compatible fixes / patches into the said
custom fork.
With those maintenance branches now gone - this model no longer works.
Given that keycloak has now over 500 forks I guess that I'm not the only
one who followed that model.
I would suggest to keep some maintenace branches for previous versions
(e.g. 2.1.x) around to enable users
to upgrade their forks in a timely manner.
Cheers,
Thomas
2016-09-09 11:34 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
> They where deleted on purpose. 2.2 is about to be released, which means
> there won't be any more 2.1 or 2.0 releases so these branches are no longer
> needed.
>
> On 9 September 2016 at 10:55, Thomas Darimont <
> thomas.darimont(a)googlemail.com> wrote:
>
>> Hello,
>>
>> just found out that some of the maintenance branches: 2.1.x, 2.0.x are
>> no longer available in in the the keycloak github repository.
>>
>> Only the 1.9.x & master branches are left :(
>>
>> Did someone accidentally remove those branches?
>>
>> Cheers,
>> Thomas
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
7:24 a.m.
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.
7:33 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7:47 a.m.
On 09/09/2016 02:33 PM, Bill Burke wrote:
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.
That's perfectly acceptable. Just add that to a CONTRIBUTING.md, so that
people are aware that this is the policy.
- Juca.
10:35 a.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:26 p.m.
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(a)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:
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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
6:36 a.m.
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.
On 9/9/16 11:35 AM, Thomas Darimont 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:
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(a)redhat.com
<mailto: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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
7:24 a.m.
2.1 is tagged, can't you just create a branch off of that tag?
On 9/9/16 8:17 AM, 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).
Why not just base your branch of the Final tag?
On 9 September 2016 at 11:59, Thomas Darimont
<thomas.darimont(a)googlemail.com
<mailto:thomas.darimont@googlemail.com>> wrote:
Hello,
I think it would have been helpful to announce that on the
keycloak-user /-dev mailing-lists and Keycloak blog.
(In case it was announced - it was IMHO not stressed enough).
Some folks (including me) based their internal forks of Keycloak
on top of a "maintenance branch" like 2.1.x
expecting to be able to channel compatible fixes / patches into
the said custom fork.
With those maintenance branches now gone - this model no longer works.
Given that keycloak has now over 500 forks I guess that I'm not
the only one who followed that model.
I would suggest to keep some maintenace branches for previous
versions (e.g. 2.1.x) around to enable users
to upgrade their forks in a timely manner.
Cheers,
Thomas
2016-09-09 11:34 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com
<mailto:sthorger@redhat.com>>:
They where deleted on purpose. 2.2 is about to be released,
which means there won't be any more 2.1 or 2.0 releases so
these branches are no longer needed.
On 9 September 2016 at 10:55, Thomas Darimont
<thomas.darimont(a)googlemail.com
<mailto:thomas.darimont@googlemail.com>> wrote:
Hello,
just found out that some of the maintenance branches:
2.1.x, 2.0.x are no longer available in in the the
keycloak github repository.
Only the 1.9.x & master branches are left :(
Did someone accidentally remove those branches?
Cheers,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3029
days inactive
3030
days old
10 comments
4 participants
participants (4)
-
Bill Burke -
Juraci Paixão Kröhling -
Stian Thorgersen -
Thomas Darimont