1 p.m.
Good afternoon,
During our stand-up meeting today we discussed the versioning of the
new Keycloak Operator. In summary, if the versioning should follow the
same scheme as semantic versioning, or follow our continuous delivery
model[1].
The "old" Operator is actually on 1.9.4 and the new version should be
2.0.0. But if we use our current versioning scheme, that means a
significant bump, for example, 8.0.0.
I kind of know the answer :) But the team wanted to ask.
[1] - https://www.keycloak.org/2019/04/versioning.html
--
- abstractj
1:16 p.m.
re: version numbers
Users of the software will want to know which version of X is compatible
with which version of Y.
This seems very relevant to an operator.
One way of doing this is by keeping the major version numbers matching when
the software has compatibility.
Kind regards,
Johnny
--
Johnny Muczynski
SimuQuest, Inc.
35 Research Dr. Ste 400
Ann Arbor, MI 48103
cell: 734-262-2045
On Tue, Nov 5, 2019 at 2:04 PM Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good afternoon,
During our stand-up meeting today we discussed the versioning of the
new Keycloak Operator. In summary, if the versioning should follow the
same scheme as semantic versioning, or follow our continuous delivery
model[1].
The "old" Operator is actually on 1.9.4 and the new version should be
2.0.0. But if we use our current versioning scheme, that means a
significant bump, for example, 8.0.0.
I kind of know the answer :) But the team wanted to ask.
[1] - https://www.keycloak.org/2019/04/versioning.html
--
- abstractj
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:22 a.m.
The simple approach is to release the operator together with all other bits
and bobs and have the version identical to Keycloak upstream, and identical
to RH-SSO downstream. Anything other than that needs more discussion and
consideration.
To add a bit more context. Today we release Keycloak server, Java adapters,
Node.js adapter and Gatekeeper, all with the same version. This simplifies
the release process both for upstream and downstream. It also simplifies
documentation as there is a single version to worry about. Doing different
release cadence for different bits may have some benefits, but would be a
fair amount of work upfront and would also add overhead on a
release-by-release basis.
For semver. We don't follow semver. We aim a continuous model where we have
deprecation of features, rather than major breaking changes.
With regards to compatibility the simplest would be to require
matching versions of operator and software. Anything else would need
documenting compatibility as well as testing a matrix of versions together.
On Tue, 5 Nov 2019 at 20:25, Johnny Muczynski <jmuczynski(a)simuquest.com>
wrote:
re: version numbers
Users of the software will want to know which version of X is compatible
with which version of Y.
This seems very relevant to an operator.
One way of doing this is by keeping the major version numbers matching when
the software has compatibility.
Kind regards,
Johnny
--
Johnny Muczynski
SimuQuest, Inc.
35 Research Dr. Ste 400
Ann Arbor, MI 48103
cell: 734-262-2045
On Tue, Nov 5, 2019 at 2:04 PM Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Good afternoon,
>
> During our stand-up meeting today we discussed the versioning of the
> new Keycloak Operator. In summary, if the versioning should follow the
> same scheme as semantic versioning, or follow our continuous delivery
> model[1].
>
> The "old" Operator is actually on 1.9.4 and the new version should be
> 2.0.0. But if we use our current versioning scheme, that means a
> significant bump, for example, 8.0.0.
>
> I kind of know the answer :) But the team wanted to ask.
>
> [1] - https://www.keycloak.org/2019/04/versioning.html
>
> --
> - abstractj
> _______________________________________________
> 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
2:07 a.m.
On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good afternoon,
During our stand-up meeting today we discussed the versioning of the
new Keycloak Operator. In summary, if the versioning should follow the
same scheme as semantic versioning, or follow our continuous delivery
model[1].
The "old" Operator is actually on 1.9.4 and the new version should be
2.0.0. But if we use our current versioning scheme, that means a
significant bump, for example, 8.0.0.
+1 for version of the operator being aligned with the version of other
components
(server, adapters etc.), even if this will mean:
- Operator version will need initially to get bumped substantially to
match the Keycloak server version,
- Operator would need to be released together with other components this
way (IOW any, even possible urgent Operator fixes would need to wait for
N+1 server release).
This makes more sense / is more consistent IMHO, than keeping the Operator
version as a separate one.
Besides that (as already mentioned) it removes the need in the future
(maybe often?) to clarify, which
Operator version matches which Keycloak server version.
Just my two cents.
Thank you && Regards, Jan
--
Jan iankko Lieskovsky / Keycloak / RH-SSO Team
I kind of know the answer :) But the team wanted to ask.
[1] - https://www.keycloak.org/2019/04/versioning.html
--
- abstractj
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
2:53 a.m.
Ok, you convinced me guys. Let's align it with Keycloak.
On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky <jlieskov(a)redhat.com> wrote:
On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira
<bruno(a)abstractj.org> wrote:
> Good afternoon,
>
> During our stand-up meeting today we discussed the versioning of the
> new Keycloak Operator. In summary, if the versioning should follow the
> same scheme as semantic versioning, or follow our continuous delivery
> model[1].
>
> The "old" Operator is actually on 1.9.4 and the new version should be
> 2.0.0. But if we use our current versioning scheme, that means a
> significant bump, for example, 8.0.0.
>
+1 for version of the operator being aligned with the version of other
components
(server, adapters etc.), even if this will mean:
- Operator version will need initially to get bumped substantially to
match the Keycloak server version,
- Operator would need to be released together with other components this
way (IOW any, even possible urgent Operator fixes would need to wait for
N+1 server release).
This makes more sense / is more consistent IMHO, than keeping the Operator
version as a separate one.
Besides that (as already mentioned) it removes the need in the future
(maybe often?) to clarify, which
Operator version matches which Keycloak server version.
Just my two cents.
Thank you && Regards, Jan
--
Jan iankko Lieskovsky / Keycloak / RH-SSO Team
>
> I kind of know the answer :) But the team wanted to ask.
>
> [1] - https://www.keycloak.org/2019/04/versioning.html
>
> --
> - abstractj
> _______________________________________________
> 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
3:09 a.m.
Hi Stian,
I agree with your assessment since all other sub-components within Keycloak
all use the same version. I would just like to clarify one point.
have the version identical to Keycloak upstream, and identical to RH-SSO
downstream
I was under the impression these were on different versions. Keycloak 7.0.1
and RH-SSO 7.3.2? A follow on question, how long after Keycloak 8.0.0 is
release does the next version of RH-SSO get released and will this also be
8.0.0?
Thanks
DAVID FFRENCH
Principal software engineer, CLOUD SERVICES
Red Hat Waterford <https://www.redhat.com/>
Communications House, Cork Road
Waterford, Ireland
dffrench(a)redhat.com
On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <slaskawi(a)redhat.com>
wrote:
Ok, you convinced me guys. Let's align it with Keycloak.
On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky <jlieskov(a)redhat.com> wrote:
> On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <bruno(a)abstractj.org>
wrote:
>
> > Good afternoon,
> >
> > During our stand-up meeting today we discussed the versioning of the
> > new Keycloak Operator. In summary, if the versioning should follow the
> > same scheme as semantic versioning, or follow our continuous delivery
> > model[1].
> >
> > The "old" Operator is actually on 1.9.4 and the new version should
be
> > 2.0.0. But if we use our current versioning scheme, that means a
> > significant bump, for example, 8.0.0.
> >
>
> +1 for version of the operator being aligned with the version of other
> components
> (server, adapters etc.), even if this will mean:
>
> - Operator version will need initially to get bumped substantially to
> match the Keycloak server version,
> - Operator would need to be released together with other components
this
> way (IOW any, even possible urgent Operator fixes would need to wait
for
> N+1 server release).
>
> This makes more sense / is more consistent IMHO, than keeping the
Operator
> version as a separate one.
> Besides that (as already mentioned) it removes the need in the future
> (maybe often?) to clarify, which
> Operator version matches which Keycloak server version.
>
> Just my two cents.
>
>
> Thank you && Regards, Jan
> --
> Jan iankko Lieskovsky / Keycloak / RH-SSO Team
>
>
>
> >
> > I kind of know the answer :) But the team wanted to ask.
> >
> > [1] - https://www.keycloak.org/2019/04/versioning.html
> >
> > --
> > - abstractj
> > _______________________________________________
> > 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
4:30 a.m.
On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)redhat.com> wrote:
Hi Stian,
I agree with your assessment since all other sub-components within
Keycloak all use the same version. I would just like to clarify one point.
have the version identical to Keycloak upstream, and identical to RH-SSO
> downstream
I was under the impression these were on different versions. Keycloak
7.0.1 and RH-SSO 7.3.2? A follow on question, how long after Keycloak 8.0.0
is release does the next version of RH-SSO get released and will this also
be 8.0.0?
Yes/no ;)
RH-SSO has two versions. The product version (7.3.0.GA for example) and the
underlying productized Keycloak version (4.8.3.Final-redhat-0001). RH-SSO
7.4.0.GA will be based on the latest Keycloak release at the time (this
will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO micro
releases these are based on Keycloak micros (so RH-SSO 7.3.2 was Keycloak
4.8.12 or something like that, can't remember the exact one). As a
side-note we don't do micro releases of older Keycloak versions to the
community, so branches and releases of these are not available to the
public.
Thanks
DAVID FFRENCH
Principal software engineer, CLOUD SERVICES
Red Hat Waterford <https://www.redhat.com/>
Communications House, Cork Road
Waterford, Ireland
dffrench(a)redhat.com
On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <slaskawi(a)redhat.com>
wrote:
> Ok, you convinced me guys. Let's align it with Keycloak.
>
> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky <jlieskov(a)redhat.com>
> wrote:
>
> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <bruno(a)abstractj.org>
> wrote:
> >
> > > Good afternoon,
> > >
> > > During our stand-up meeting today we discussed the versioning of the
> > > new Keycloak Operator. In summary, if the versioning should follow the
> > > same scheme as semantic versioning, or follow our continuous delivery
> > > model[1].
> > >
> > > The "old" Operator is actually on 1.9.4 and the new version
should be
> > > 2.0.0. But if we use our current versioning scheme, that means a
> > > significant bump, for example, 8.0.0.
> > >
> >
> > +1 for version of the operator being aligned with the version of other
> > components
> > (server, adapters etc.), even if this will mean:
> >
> > - Operator version will need initially to get bumped substantially to
> > match the Keycloak server version,
> > - Operator would need to be released together with other components
> this
> > way (IOW any, even possible urgent Operator fixes would need to wait
> for
> > N+1 server release).
> >
> > This makes more sense / is more consistent IMHO, than keeping the
> Operator
> > version as a separate one.
> > Besides that (as already mentioned) it removes the need in the future
> > (maybe often?) to clarify, which
> > Operator version matches which Keycloak server version.
> >
> > Just my two cents.
> >
> >
> > Thank you && Regards, Jan
> > --
> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
> >
> >
> >
> > >
> > > I kind of know the answer :) But the team wanted to ask.
> > >
> > > [1] - https://www.keycloak.org/2019/04/versioning.html
> > >
> > > --
> > > - abstractj
> > > _______________________________________________
> > > 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
>
4:50 a.m.
So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3 and
RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our Operator on
the Keycloak version (8.0.0) then the user wouldn't necessarily know what
RH-SSO version they would get (the operator can also install RH-SSO).
It sounds like we should base it on the RH-SSO version then, so the
Operator would be v7.4.0 which tells the user that they can either get
RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
Does that make sense?
On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
On Wed, 6 Nov 2019 at 10:10, David Ffrench
<dffrench(a)redhat.com> wrote:
> Hi Stian,
>
> I agree with your assessment since all other sub-components within
> Keycloak all use the same version. I would just like to clarify one
point.
>
> have the version identical to Keycloak upstream, and identical to RH-SSO
>> downstream
>
> I was under the impression these were on different versions. Keycloak
> 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after Keycloak
8.0.0
> is release does the next version of RH-SSO get released and will this
also
> be 8.0.0?
>
Yes/no ;)
RH-SSO has two versions. The product version (7.3.0.GA for example) and
the
underlying productized Keycloak version (4.8.3.Final-redhat-0001). RH-SSO
7.4.0.GA will be based on the latest Keycloak release at the time (this
will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO micro
releases these are based on Keycloak micros (so RH-SSO 7.3.2 was Keycloak
4.8.12 or something like that, can't remember the exact one). As a
side-note we don't do micro releases of older Keycloak versions to the
community, so branches and releases of these are not available to the
public.
>
> Thanks
>
> DAVID FFRENCH
>
> Principal software engineer, CLOUD SERVICES
>
> Red Hat Waterford <https://www.redhat.com/>
>
> Communications House, Cork Road
>
> Waterford, Ireland
>
> dffrench(a)redhat.com
>
>
>
>
>
> On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <slaskawi(a)redhat.com>
> wrote:
>
>> Ok, you convinced me guys. Let's align it with Keycloak.
>>
>> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky <jlieskov(a)redhat.com>
>> wrote:
>>
>> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <bruno(a)abstractj.org>
>> wrote:
>> >
>> > > Good afternoon,
>> > >
>> > > During our stand-up meeting today we discussed the versioning of the
>> > > new Keycloak Operator. In summary, if the versioning should follow
the
>> > > same scheme as semantic versioning, or follow our continuous
delivery
>> > > model[1].
>> > >
>> > > The "old" Operator is actually on 1.9.4 and the new version
should
be
>> > > 2.0.0. But if we use our current versioning scheme, that means a
>> > > significant bump, for example, 8.0.0.
>> > >
>> >
>> > +1 for version of the operator being aligned with the version of other
>> > components
>> > (server, adapters etc.), even if this will mean:
>> >
>> > - Operator version will need initially to get bumped substantially
to
>> > match the Keycloak server version,
>> > - Operator would need to be released together with other components
>> this
>> > way (IOW any, even possible urgent Operator fixes would need to
wait
>> for
>> > N+1 server release).
>> >
>> > This makes more sense / is more consistent IMHO, than keeping the
>> Operator
>> > version as a separate one.
>> > Besides that (as already mentioned) it removes the need in the future
>> > (maybe often?) to clarify, which
>> > Operator version matches which Keycloak server version.
>> >
>> > Just my two cents.
>> >
>> >
>> > Thank you && Regards, Jan
>> > --
>> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
>> >
>> >
>> >
>> > >
>> > > I kind of know the answer :) But the team wanted to ask.
>> > >
>> > > [1] - https://www.keycloak.org/2019/04/versioning.html
>> > >
>> > > --
>> > > - abstractj
>> > > _______________________________________________
>> > > 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
>>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:07 a.m.
On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)redhat.com> wrote:
So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3
and
RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our Operator on
the Keycloak version (8.0.0) then the user wouldn't necessarily know what
RH-SSO version they would get (the operator can also install RH-SSO).
RH-SSO 7.4 will most likely be based on Keycloak 9.
It sounds like we should base it on the RH-SSO version then, so the
Operator would be v7.4.0 which tells the user that they can either get
RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
Does that make sense?
There should be two separate versions of the operator. One community which
will have version based on Keycloak, and another one for product, which
should be based on RH-SSO versions. There is also a difference in
maintenance/support for the Keycloak and the RH-SSO operator. The Keycloak
operator will be released together with Keycloak, with no micro updates
(unless there are critical bugs or CVEs), while the RH-SSO release has
micro releases for roughly a year.
On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)redhat.com> wrote:
>
> > Hi Stian,
> >
> > I agree with your assessment since all other sub-components within
> > Keycloak all use the same version. I would just like to clarify one
> point.
> >
> > have the version identical to Keycloak upstream, and identical to RH-SSO
> >> downstream
> >
> > I was under the impression these were on different versions. Keycloak
> > 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after Keycloak
> 8.0.0
> > is release does the next version of RH-SSO get released and will this
> also
> > be 8.0.0?
> >
>
> Yes/no ;)
>
> RH-SSO has two versions. The product version (7.3.0.GA for example) and
> the
> underlying productized Keycloak version (4.8.3.Final-redhat-0001). RH-SSO
> 7.4.0.GA will be based on the latest Keycloak release at the time (this
> will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO
> micro
> releases these are based on Keycloak micros (so RH-SSO 7.3.2 was Keycloak
> 4.8.12 or something like that, can't remember the exact one). As a
> side-note we don't do micro releases of older Keycloak versions to the
> community, so branches and releases of these are not available to the
> public.
>
>
> >
> > Thanks
> >
> > DAVID FFRENCH
> >
> > Principal software engineer, CLOUD SERVICES
> >
> > Red Hat Waterford <https://www.redhat.com/>
> >
> > Communications House, Cork Road
> >
> > Waterford, Ireland
> >
> > dffrench(a)redhat.com
> >
> >
> >
> >
> >
> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <slaskawi(a)redhat.com
> >
> > wrote:
> >
> >> Ok, you convinced me guys. Let's align it with Keycloak.
> >>
> >> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky <jlieskov(a)redhat.com>
> >> wrote:
> >>
> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira
<bruno(a)abstractj.org>
> >> wrote:
> >> >
> >> > > Good afternoon,
> >> > >
> >> > > During our stand-up meeting today we discussed the versioning of
> the
> >> > > new Keycloak Operator. In summary, if the versioning should
follow
> the
> >> > > same scheme as semantic versioning, or follow our continuous
> delivery
> >> > > model[1].
> >> > >
> >> > > The "old" Operator is actually on 1.9.4 and the new
version should
> be
> >> > > 2.0.0. But if we use our current versioning scheme, that means a
> >> > > significant bump, for example, 8.0.0.
> >> > >
> >> >
> >> > +1 for version of the operator being aligned with the version of
> other
> >> > components
> >> > (server, adapters etc.), even if this will mean:
> >> >
> >> > - Operator version will need initially to get bumped
> substantially to
> >> > match the Keycloak server version,
> >> > - Operator would need to be released together with other
> components
> >> this
> >> > way (IOW any, even possible urgent Operator fixes would need to
> wait
> >> for
> >> > N+1 server release).
> >> >
> >> > This makes more sense / is more consistent IMHO, than keeping the
> >> Operator
> >> > version as a separate one.
> >> > Besides that (as already mentioned) it removes the need in the future
> >> > (maybe often?) to clarify, which
> >> > Operator version matches which Keycloak server version.
> >> >
> >> > Just my two cents.
> >> >
> >> >
> >> > Thank you && Regards, Jan
> >> > --
> >> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
> >> >
> >> >
> >> >
> >> > >
> >> > > I kind of know the answer :) But the team wanted to ask.
> >> > >
> >> > > [1] - https://www.keycloak.org/2019/04/versioning.html
> >> > >
> >> > > --
> >> > > - abstractj
> >> > > _______________________________________________
> >> > > 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
> >>
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
11:27 a.m.
There should be two separate versions of the operator. One community which
will have version based on Keycloak, and another one for product, which
should be based on RH-SSO versions. There is also a difference in
maintenance/support for the Keycloak and the RH-SSO operator. The Keycloak
operator will be released together with Keycloak, with no micro updates
(unless there are critical bugs or CVEs), while the RH-SSO release has
micro releases for roughly a year.
Thanks, Stian. This seems to be where the confusion lies. The current
operator allows you to create either a Keycloak or an RH-SSO instance based
on a value in the CR spec. Since it supports both, I was finding it hard to
understand which to map the version too. I would still be happy for the non
productised operator to support both, with the version mapped to Keycloak.
You can only create RH-SSO if you have a pull secret in the namespace for
pulling those images. The productised operator can then be mapped to RH-SSO
in the future and still support both also in my opinion but default to
RH-SSO.
DAVID FFRENCH
Principal software engineer, CLOUD SERVICES
Red Hat Waterford <https://www.redhat.com/>
Communications House, Cork Road
Waterford, Ireland
dffrench(a)redhat.com
On Wed, Nov 6, 2019 at 11:07 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>
>
> On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)redhat.com> wrote:
>
>> So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3 and
>> RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our Operator on
>> the Keycloak version (8.0.0) then the user wouldn't necessarily know what
>> RH-SSO version they would get (the operator can also install RH-SSO).
>>
>
> RH-SSO 7.4 will most likely be based on Keycloak 9.
>
>
>>
>> It sounds like we should base it on the RH-SSO version then, so the
>> Operator would be v7.4.0 which tells the user that they can either get
>> RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
>>
>> Does that make sense?
>>
There should be two separate versions of the operator. One community which
will have version based on Keycloak, and another one for product, which
should be based on RH-SSO versions. There is also a difference in
maintenance/support for the Keycloak and the RH-SSO operator. The Keycloak
operator will be released together with Keycloak, with no micro updates
(unless there are critical bugs or CVEs), while the RH-SSO release has
micro releases for roughly a year.
>
>
>>
>>
>>
>> On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <sthorger(a)redhat.com>
>> wrote:
>>
>>> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)redhat.com>
wrote:
>>>
>>> > Hi Stian,
>>> >
>>> > I agree with your assessment since all other sub-components within
>>> > Keycloak all use the same version. I would just like to clarify one
>>> point.
>>> >
>>> > have the version identical to Keycloak upstream, and identical to
>>> RH-SSO
>>> >> downstream
>>> >
>>> > I was under the impression these were on different versions. Keycloak
>>> > 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after Keycloak
>>> 8.0.0
>>> > is release does the next version of RH-SSO get released and will this
>>> also
>>> > be 8.0.0?
>>> >
>>>
>>> Yes/no ;)
>>>
>>> RH-SSO has two versions. The product version (7.3.0.GA for example) and
>>> the
>>> underlying productized Keycloak version (4.8.3.Final-redhat-0001). RH-SSO
>>> 7.4.0.GA will be based on the latest Keycloak release at the time (this
>>> will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO
>>> micro
>>> releases these are based on Keycloak micros (so RH-SSO 7.3.2 was Keycloak
>>> 4.8.12 or something like that, can't remember the exact one). As a
>>> side-note we don't do micro releases of older Keycloak versions to the
>>> community, so branches and releases of these are not available to the
>>> public.
>>>
>>>
>>> >
>>> > Thanks
>>> >
>>> > DAVID FFRENCH
>>> >
>>> > Principal software engineer, CLOUD SERVICES
>>> >
>>> > Red Hat Waterford <https://www.redhat.com/>
>>> >
>>> > Communications House, Cork Road
>>> >
>>> > Waterford, Ireland
>>> >
>>> > dffrench(a)redhat.com
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <
>>> slaskawi(a)redhat.com>
>>> > wrote:
>>> >
>>> >> Ok, you convinced me guys. Let's align it with Keycloak.
>>> >>
>>> >> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky
<jlieskov(a)redhat.com>
>>> >> wrote:
>>> >>
>>> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira
<bruno(a)abstractj.org>
>>> >> wrote:
>>> >> >
>>> >> > > Good afternoon,
>>> >> > >
>>> >> > > During our stand-up meeting today we discussed the
versioning of
>>> the
>>> >> > > new Keycloak Operator. In summary, if the versioning
should
>>> follow the
>>> >> > > same scheme as semantic versioning, or follow our
continuous
>>> delivery
>>> >> > > model[1].
>>> >> > >
>>> >> > > The "old" Operator is actually on 1.9.4 and the
new version
>>> should be
>>> >> > > 2.0.0. But if we use our current versioning scheme, that
means a
>>> >> > > significant bump, for example, 8.0.0.
>>> >> > >
>>> >> >
>>> >> > +1 for version of the operator being aligned with the version
of
>>> other
>>> >> > components
>>> >> > (server, adapters etc.), even if this will mean:
>>> >> >
>>> >> > - Operator version will need initially to get bumped
>>> substantially to
>>> >> > match the Keycloak server version,
>>> >> > - Operator would need to be released together with other
>>> components
>>> >> this
>>> >> > way (IOW any, even possible urgent Operator fixes would need
to
>>> wait
>>> >> for
>>> >> > N+1 server release).
>>> >> >
>>> >> > This makes more sense / is more consistent IMHO, than keeping
the
>>> >> Operator
>>> >> > version as a separate one.
>>> >> > Besides that (as already mentioned) it removes the need in the
>>> future
>>> >> > (maybe often?) to clarify, which
>>> >> > Operator version matches which Keycloak server version.
>>> >> >
>>> >> > Just my two cents.
>>> >> >
>>> >> >
>>> >> > Thank you && Regards, Jan
>>> >> > --
>>> >> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
>>> >> >
>>> >> >
>>> >> >
>>> >> > >
>>> >> > > I kind of know the answer :) But the team wanted to ask.
>>> >> > >
>>> >> > > [1] - https://www.keycloak.org/2019/04/versioning.html
>>> >> > >
>>> >> > > --
>>> >> > > - abstractj
>>> >> > > _______________________________________________
>>> >> > > 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
>>> >>
>>> >
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
6:49 a.m.
Support is not the right word here. As that implies it is a tested and
documented combination.
Keycloak operator can not support RH-SSO, RH-SSO operator can not support
Keycloak. Otherwise, we would have to document and test the combinations,
which doesn't really make that much sense.
From an implementation standpoint it's okay the code is there, but
needs to
default to the correct images, and it shouldn't be documented/tested.
On Wed, 6 Nov 2019 at 18:27, David Ffrench <dffrench(a)redhat.com> wrote:
There should be two separate versions of the operator. One community
which
> will have version based on Keycloak, and another one for product, which
> should be based on RH-SSO versions. There is also a difference in
> maintenance/support for the Keycloak and the RH-SSO operator. The Keycloak
> operator will be released together with Keycloak, with no micro updates
> (unless there are critical bugs or CVEs), while the RH-SSO release has
> micro releases for roughly a year.
Thanks, Stian. This seems to be where the confusion lies. The current
operator allows you to create either a Keycloak or an RH-SSO instance based
on a value in the CR spec. Since it supports both, I was finding it hard to
understand which to map the version too. I would still be happy for the non
productised operator to support both, with the version mapped to Keycloak.
You can only create RH-SSO if you have a pull secret in the namespace for
pulling those images. The productised operator can then be mapped to RH-SSO
in the future and still support both also in my opinion but default to
RH-SSO.
DAVID FFRENCH
Principal software engineer, CLOUD SERVICES
Red Hat Waterford <https://www.redhat.com/>
Communications House, Cork Road
Waterford, Ireland
dffrench(a)redhat.com
On Wed, Nov 6, 2019 at 11:07 AM Stian Thorgersen <sthorger(a)redhat.com>
wrote:
>
>
> On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)redhat.com> wrote:
>
>> So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3 and
>> RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our Operator on
>> the Keycloak version (8.0.0) then the user wouldn't necessarily know what
>> RH-SSO version they would get (the operator can also install RH-SSO).
>>
>
> RH-SSO 7.4 will most likely be based on Keycloak 9.
>
>
>>
>> It sounds like we should base it on the RH-SSO version then, so the
>> Operator would be v7.4.0 which tells the user that they can either get
>> RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
>>
>> Does that make sense?
>>
>
> There should be two separate versions of the operator. One community
> which will have version based on Keycloak, and another one for product,
> which should be based on RH-SSO versions. There is also a difference in
> maintenance/support for the Keycloak and the RH-SSO operator. The Keycloak
> operator will be released together with Keycloak, with no micro updates
> (unless there are critical bugs or CVEs), while the RH-SSO release has
> micro releases for roughly a year.
>
>
>>
>>
>>
>> On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <sthorger(a)redhat.com>
>> wrote:
>>
>>> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)redhat.com>
wrote:
>>>
>>> > Hi Stian,
>>> >
>>> > I agree with your assessment since all other sub-components within
>>> > Keycloak all use the same version. I would just like to clarify one
>>> point.
>>> >
>>> > have the version identical to Keycloak upstream, and identical to
>>> RH-SSO
>>> >> downstream
>>> >
>>> > I was under the impression these were on different versions. Keycloak
>>> > 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after Keycloak
>>> 8.0.0
>>> > is release does the next version of RH-SSO get released and will this
>>> also
>>> > be 8.0.0?
>>> >
>>>
>>> Yes/no ;)
>>>
>>> RH-SSO has two versions. The product version (7.3.0.GA for example)
>>> and the
>>> underlying productized Keycloak version (4.8.3.Final-redhat-0001).
>>> RH-SSO
>>> 7.4.0.GA will be based on the latest Keycloak release at the time (this
>>> will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO
>>> micro
>>> releases these are based on Keycloak micros (so RH-SSO 7.3.2 was
>>> Keycloak
>>> 4.8.12 or something like that, can't remember the exact one). As a
>>> side-note we don't do micro releases of older Keycloak versions to the
>>> community, so branches and releases of these are not available to the
>>> public.
>>>
>>>
>>> >
>>> > Thanks
>>> >
>>> > DAVID FFRENCH
>>> >
>>> > Principal software engineer, CLOUD SERVICES
>>> >
>>> > Red Hat Waterford <https://www.redhat.com/>
>>> >
>>> > Communications House, Cork Road
>>> >
>>> > Waterford, Ireland
>>> >
>>> > dffrench(a)redhat.com
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <
>>> slaskawi(a)redhat.com>
>>> > wrote:
>>> >
>>> >> Ok, you convinced me guys. Let's align it with Keycloak.
>>> >>
>>> >> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky
<jlieskov(a)redhat.com>
>>> >> wrote:
>>> >>
>>> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira
<bruno(a)abstractj.org
>>> >
>>> >> wrote:
>>> >> >
>>> >> > > Good afternoon,
>>> >> > >
>>> >> > > During our stand-up meeting today we discussed the
versioning of
>>> the
>>> >> > > new Keycloak Operator. In summary, if the versioning
should
>>> follow the
>>> >> > > same scheme as semantic versioning, or follow our
continuous
>>> delivery
>>> >> > > model[1].
>>> >> > >
>>> >> > > The "old" Operator is actually on 1.9.4 and the
new version
>>> should be
>>> >> > > 2.0.0. But if we use our current versioning scheme, that
means a
>>> >> > > significant bump, for example, 8.0.0.
>>> >> > >
>>> >> >
>>> >> > +1 for version of the operator being aligned with the version
of
>>> other
>>> >> > components
>>> >> > (server, adapters etc.), even if this will mean:
>>> >> >
>>> >> > - Operator version will need initially to get bumped
>>> substantially to
>>> >> > match the Keycloak server version,
>>> >> > - Operator would need to be released together with other
>>> components
>>> >> this
>>> >> > way (IOW any, even possible urgent Operator fixes would need
to
>>> wait
>>> >> for
>>> >> > N+1 server release).
>>> >> >
>>> >> > This makes more sense / is more consistent IMHO, than keeping
the
>>> >> Operator
>>> >> > version as a separate one.
>>> >> > Besides that (as already mentioned) it removes the need in the
>>> future
>>> >> > (maybe often?) to clarify, which
>>> >> > Operator version matches which Keycloak server version.
>>> >> >
>>> >> > Just my two cents.
>>> >> >
>>> >> >
>>> >> > Thank you && Regards, Jan
>>> >> > --
>>> >> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
>>> >> >
>>> >> >
>>> >> >
>>> >> > >
>>> >> > > I kind of know the answer :) But the team wanted to ask.
>>> >> > >
>>> >> > > [1] - https://www.keycloak.org/2019/04/versioning.html
>>> >> > >
>>> >> > > --
>>> >> > > - abstractj
>>> >> > > _______________________________________________
>>> >> > > 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
>>> >>
>>> >
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
7:26 a.m.
----- Original Message -----
On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)redhat.com>
wrote:
> So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3 and
> RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our Operator on
> the Keycloak version (8.0.0) then the user wouldn't necessarily know what
> RH-SSO version they would get (the operator can also install RH-SSO).
>
RH-SSO 7.4 will most likely be based on Keycloak 9.
>
> It sounds like we should base it on the RH-SSO version then, so the
> Operator would be v7.4.0 which tells the user that they can either get
> RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
>
> Does that make sense?
>
There should be two separate versions of the operator. One community which
will have version based on Keycloak, and another one for product, which
should be based on RH-SSO versions. There is also a difference in
maintenance/support for the Keycloak and the RH-SSO operator. The Keycloak
operator will be released together with Keycloak, with no micro updates
(unless there are critical bugs or CVEs), while the RH-SSO release has
micro releases for roughly a year.
Since the versioning would be 1-1 would it make sense to develop the operator directly as
Keycloak project/product module?
>
>
>
> On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)redhat.com> wrote:
>>
>> > Hi Stian,
>> >
>> > I agree with your assessment since all other sub-components within
>> > Keycloak all use the same version. I would just like to clarify one
>> point.
>> >
>> > have the version identical to Keycloak upstream, and identical to RH-SSO
>> >> downstream
>> >
>> > I was under the impression these were on different versions. Keycloak
>> > 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after Keycloak
>> 8.0.0
>> > is release does the next version of RH-SSO get released and will this
>> also
>> > be 8.0.0?
>> >
>>
>> Yes/no ;)
>>
>> RH-SSO has two versions. The product version (7.3.0.GA for example) and
>> the
>> underlying productized Keycloak version (4.8.3.Final-redhat-0001). RH-SSO
>> 7.4.0.GA will be based on the latest Keycloak release at the time (this
>> will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO
>> micro
>> releases these are based on Keycloak micros (so RH-SSO 7.3.2 was Keycloak
>> 4.8.12 or something like that, can't remember the exact one). As a
>> side-note we don't do micro releases of older Keycloak versions to the
>> community, so branches and releases of these are not available to the
>> public.
>>
>>
>> >
>> > Thanks
>> >
>> > DAVID FFRENCH
>> >
>> > Principal software engineer, CLOUD SERVICES
>> >
>> > Red Hat Waterford <https://www.redhat.com/>
>> >
>> > Communications House, Cork Road
>> >
>> > Waterford, Ireland
>> >
>> > dffrench(a)redhat.com
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <slaskawi(a)redhat.com
>> >
>> > wrote:
>> >
>> >> Ok, you convinced me guys. Let's align it with Keycloak.
>> >>
>> >> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky
<jlieskov(a)redhat.com>
>> >> wrote:
>> >>
>> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira
<bruno(a)abstractj.org>
>> >> wrote:
>> >> >
>> >> > > Good afternoon,
>> >> > >
>> >> > > During our stand-up meeting today we discussed the versioning
of
>> the
>> >> > > new Keycloak Operator. In summary, if the versioning should
follow
>> the
>> >> > > same scheme as semantic versioning, or follow our continuous
>> delivery
>> >> > > model[1].
>> >> > >
>> >> > > The "old" Operator is actually on 1.9.4 and the new
version should
>> be
>> >> > > 2.0.0. But if we use our current versioning scheme, that
means a
>> >> > > significant bump, for example, 8.0.0.
>> >> > >
>> >> >
>> >> > +1 for version of the operator being aligned with the version of
>> other
>> >> > components
>> >> > (server, adapters etc.), even if this will mean:
>> >> >
>> >> > - Operator version will need initially to get bumped
>> substantially to
>> >> > match the Keycloak server version,
>> >> > - Operator would need to be released together with other
>> components
>> >> this
>> >> > way (IOW any, even possible urgent Operator fixes would need
to
>> wait
>> >> for
>> >> > N+1 server release).
>> >> >
>> >> > This makes more sense / is more consistent IMHO, than keeping the
>> >> Operator
>> >> > version as a separate one.
>> >> > Besides that (as already mentioned) it removes the need in the
future
>> >> > (maybe often?) to clarify, which
>> >> > Operator version matches which Keycloak server version.
>> >> >
>> >> > Just my two cents.
>> >> >
>> >> >
>> >> > Thank you && Regards, Jan
>> >> > --
>> >> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
>> >> >
>> >> >
>> >> >
>> >> > >
>> >> > > I kind of know the answer :) But the team wanted to ask.
>> >> > >
>> >> > > [1] - https://www.keycloak.org/2019/04/versioning.html
>> >> > >
>> >> > > --
>> >> > > - abstractj
>> >> > > _______________________________________________
>> >> > > 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
>> >>
>> >
>> _______________________________________________
>> 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
9:48 a.m.
Thanks Stian. I would agree with the word support.
So I think we are all in agreement that the Keycloak Operators initial
version should be 7.x.x to match the version of Keycloak included. Follow
on question, should it be exactly 7.0.1 to match the version of Keycloak
included? What then happens if there is a new release needed for the
operator but not keycloak itself. This would then mean an operator version
7.0.2 matches Keycloak version 7.0.1.
One way around this to only align the major version of the operator to the
major version of Keycloak and document what version of Keycloak is included.
DAVID FFRENCH
Principal software engineer, CLOUD SERVICES
Red Hat Waterford <https://www.redhat.com/>
Communications House, Cork Road
Waterford, Ireland
dffrench(a)redhat.com
On Thu, Nov 7, 2019 at 1:28 PM Tomas Kyjovsky <tkyjovsk(a)redhat.com> wrote:
----- Original Message -----
> On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)redhat.com> wrote:
>
> > So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3 and
> > RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our Operator
on
> > the Keycloak version (8.0.0) then the user wouldn't necessarily know
what
> > RH-SSO version they would get (the operator can also install RH-SSO).
> >
>
> RH-SSO 7.4 will most likely be based on Keycloak 9.
>
>
> >
> > It sounds like we should base it on the RH-SSO version then, so the
> > Operator would be v7.4.0 which tells the user that they can either get
> > RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
> >
> > Does that make sense?
> >
>
> There should be two separate versions of the operator. One community
which
> will have version based on Keycloak, and another one for product, which
> should be based on RH-SSO versions. There is also a difference in
> maintenance/support for the Keycloak and the RH-SSO operator. The
Keycloak
> operator will be released together with Keycloak, with no micro updates
> (unless there are critical bugs or CVEs), while the RH-SSO release has
> micro releases for roughly a year.
Since the versioning would be 1-1 would it make sense to develop the
operator directly as Keycloak project/product module?
>
>
> >
> >
> >
> > On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <sthorger(a)redhat.com>
> > wrote:
> >
> >> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)redhat.com>
wrote:
> >>
> >> > Hi Stian,
> >> >
> >> > I agree with your assessment since all other sub-components within
> >> > Keycloak all use the same version. I would just like to clarify one
> >> point.
> >> >
> >> > have the version identical to Keycloak upstream, and identical to
RH-SSO
> >> >> downstream
> >> >
> >> > I was under the impression these were on different versions.
Keycloak
> >> > 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after
Keycloak
> >> 8.0.0
> >> > is release does the next version of RH-SSO get released and will
this
> >> also
> >> > be 8.0.0?
> >> >
> >>
> >> Yes/no ;)
> >>
> >> RH-SSO has two versions. The product version (7.3.0.GA for example)
and
> >> the
> >> underlying productized Keycloak version (4.8.3.Final-redhat-0001).
RH-SSO
> >> 7.4.0.GA will be based on the latest Keycloak release at the time
(this
> >> will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO
> >> micro
> >> releases these are based on Keycloak micros (so RH-SSO 7.3.2 was
Keycloak
> >> 4.8.12 or something like that, can't remember the exact one). As a
> >> side-note we don't do micro releases of older Keycloak versions to the
> >> community, so branches and releases of these are not available to the
> >> public.
> >>
> >>
> >> >
> >> > Thanks
> >> >
> >> > DAVID FFRENCH
> >> >
> >> > Principal software engineer, CLOUD SERVICES
> >> >
> >> > Red Hat Waterford <https://www.redhat.com/>
> >> >
> >> > Communications House, Cork Road
> >> >
> >> > Waterford, Ireland
> >> >
> >> > dffrench(a)redhat.com
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <
slaskawi(a)redhat.com
> >> >
> >> > wrote:
> >> >
> >> >> Ok, you convinced me guys. Let's align it with Keycloak.
> >> >>
> >> >> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky
<jlieskov(a)redhat.com
>
> >> >> wrote:
> >> >>
> >> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <
bruno(a)abstractj.org>
> >> >> wrote:
> >> >> >
> >> >> > > Good afternoon,
> >> >> > >
> >> >> > > During our stand-up meeting today we discussed the
versioning
of
> >> the
> >> >> > > new Keycloak Operator. In summary, if the versioning
should
follow
> >> the
> >> >> > > same scheme as semantic versioning, or follow our
continuous
> >> delivery
> >> >> > > model[1].
> >> >> > >
> >> >> > > The "old" Operator is actually on 1.9.4 and
the new version
should
> >> be
> >> >> > > 2.0.0. But if we use our current versioning scheme, that
means
a
> >> >> > > significant bump, for example, 8.0.0.
> >> >> > >
> >> >> >
> >> >> > +1 for version of the operator being aligned with the version
of
> >> other
> >> >> > components
> >> >> > (server, adapters etc.), even if this will mean:
> >> >> >
> >> >> > - Operator version will need initially to get bumped
> >> substantially to
> >> >> > match the Keycloak server version,
> >> >> > - Operator would need to be released together with other
> >> components
> >> >> this
> >> >> > way (IOW any, even possible urgent Operator fixes would
need
to
> >> wait
> >> >> for
> >> >> > N+1 server release).
> >> >> >
> >> >> > This makes more sense / is more consistent IMHO, than keeping
the
> >> >> Operator
> >> >> > version as a separate one.
> >> >> > Besides that (as already mentioned) it removes the need in
the
future
> >> >> > (maybe often?) to clarify, which
> >> >> > Operator version matches which Keycloak server version.
> >> >> >
> >> >> > Just my two cents.
> >> >> >
> >> >> >
> >> >> > Thank you && Regards, Jan
> >> >> > --
> >> >> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
> >> >> >
> >> >> >
> >> >> >
> >> >> > >
> >> >> > > I kind of know the answer :) But the team wanted to
ask.
> >> >> > >
> >> >> > > [1] - https://www.keycloak.org/2019/04/versioning.html
> >> >> > >
> >> >> > > --
> >> >> > > - abstractj
> >> >> > > _______________________________________________
> >> >> > > 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
> >> >>
> >> >
> >> _______________________________________________
> >> 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
9:53 a.m.
On Thu, 7 Nov 2019 at 16:49, David Ffrench <dffrench(a)redhat.com> wrote:
Thanks Stian. I would agree with the word support.
So I think we are all in agreement that the Keycloak Operators initial
version should be 7.x.x to match the version of Keycloak included. Follow
on question, should it be exactly 7.0.1 to match the version of Keycloak
included? What then happens if there is a new release needed for the
operator but not keycloak itself. This would then mean an operator version
7.0.2 matches Keycloak version 7.0.1.
Our release process releases everything, so we would actually just do a
7.0.2 release if we needed an update to the operator. Most likely it would
be the other way around, as we'd probably always have something to fix in
Keycloak ;)
One way around this to only align the major version of the operator to the
major version of Keycloak and document what version of Keycloak is included.
DAVID FFRENCH
Principal software engineer, CLOUD SERVICES
Red Hat Waterford <https://www.redhat.com/>
Communications House, Cork Road
Waterford, Ireland
dffrench(a)redhat.com
On Thu, Nov 7, 2019 at 1:28 PM Tomas Kyjovsky <tkyjovsk(a)redhat.com> wrote:
>
>
> ----- Original Message -----
> > On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)redhat.com> wrote:
> >
> > > So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3
> and
> > > RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our
> Operator on
> > > the Keycloak version (8.0.0) then the user wouldn't necessarily know
> what
> > > RH-SSO version they would get (the operator can also install RH-SSO).
> > >
> >
> > RH-SSO 7.4 will most likely be based on Keycloak 9.
> >
> >
> > >
> > > It sounds like we should base it on the RH-SSO version then, so the
> > > Operator would be v7.4.0 which tells the user that they can either get
> > > RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
> > >
> > > Does that make sense?
> > >
> >
> > There should be two separate versions of the operator. One community
> which
> > will have version based on Keycloak, and another one for product, which
> > should be based on RH-SSO versions. There is also a difference in
> > maintenance/support for the Keycloak and the RH-SSO operator. The
> Keycloak
> > operator will be released together with Keycloak, with no micro updates
> > (unless there are critical bugs or CVEs), while the RH-SSO release has
> > micro releases for roughly a year.
>
> Since the versioning would be 1-1 would it make sense to develop the
> operator directly as Keycloak project/product module?
>
> >
> >
> > >
> > >
> > >
> > > On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <sthorger(a)redhat.com
> >
> > > wrote:
> > >
> > >> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)redhat.com>
> wrote:
> > >>
> > >> > Hi Stian,
> > >> >
> > >> > I agree with your assessment since all other sub-components
within
> > >> > Keycloak all use the same version. I would just like to clarify
one
> > >> point.
> > >> >
> > >> > have the version identical to Keycloak upstream, and identical to
> RH-SSO
> > >> >> downstream
> > >> >
> > >> > I was under the impression these were on different versions.
> Keycloak
> > >> > 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after
> Keycloak
> > >> 8.0.0
> > >> > is release does the next version of RH-SSO get released and will
> this
> > >> also
> > >> > be 8.0.0?
> > >> >
> > >>
> > >> Yes/no ;)
> > >>
> > >> RH-SSO has two versions. The product version (7.3.0.GA for example)
> and
> > >> the
> > >> underlying productized Keycloak version (4.8.3.Final-redhat-0001).
> RH-SSO
> > >> 7.4.0.GA will be based on the latest Keycloak release at the time
> (this
> > >> will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For RH-SSO
> > >> micro
> > >> releases these are based on Keycloak micros (so RH-SSO 7.3.2 was
> Keycloak
> > >> 4.8.12 or something like that, can't remember the exact one). As a
> > >> side-note we don't do micro releases of older Keycloak versions to
> the
> > >> community, so branches and releases of these are not available to the
> > >> public.
> > >>
> > >>
> > >> >
> > >> > Thanks
> > >> >
> > >> > DAVID FFRENCH
> > >> >
> > >> > Principal software engineer, CLOUD SERVICES
> > >> >
> > >> > Red Hat Waterford <https://www.redhat.com/>
> > >> >
> > >> > Communications House, Cork Road
> > >> >
> > >> > Waterford, Ireland
> > >> >
> > >> > dffrench(a)redhat.com
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <
> slaskawi(a)redhat.com
> > >> >
> > >> > wrote:
> > >> >
> > >> >> Ok, you convinced me guys. Let's align it with Keycloak.
> > >> >>
> > >> >> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky <
> jlieskov(a)redhat.com>
> > >> >> wrote:
> > >> >>
> > >> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <
> bruno(a)abstractj.org>
> > >> >> wrote:
> > >> >> >
> > >> >> > > Good afternoon,
> > >> >> > >
> > >> >> > > During our stand-up meeting today we discussed the
versioning
> of
> > >> the
> > >> >> > > new Keycloak Operator. In summary, if the versioning
should
> follow
> > >> the
> > >> >> > > same scheme as semantic versioning, or follow our
continuous
> > >> delivery
> > >> >> > > model[1].
> > >> >> > >
> > >> >> > > The "old" Operator is actually on 1.9.4
and the new version
> should
> > >> be
> > >> >> > > 2.0.0. But if we use our current versioning scheme,
that
> means a
> > >> >> > > significant bump, for example, 8.0.0.
> > >> >> > >
> > >> >> >
> > >> >> > +1 for version of the operator being aligned with the
version of
> > >> other
> > >> >> > components
> > >> >> > (server, adapters etc.), even if this will mean:
> > >> >> >
> > >> >> > - Operator version will need initially to get bumped
> > >> substantially to
> > >> >> > match the Keycloak server version,
> > >> >> > - Operator would need to be released together with
other
> > >> components
> > >> >> this
> > >> >> > way (IOW any, even possible urgent Operator fixes
would need
> to
> > >> wait
> > >> >> for
> > >> >> > N+1 server release).
> > >> >> >
> > >> >> > This makes more sense / is more consistent IMHO, than
keeping
> the
> > >> >> Operator
> > >> >> > version as a separate one.
> > >> >> > Besides that (as already mentioned) it removes the need
in the
> future
> > >> >> > (maybe often?) to clarify, which
> > >> >> > Operator version matches which Keycloak server version.
> > >> >> >
> > >> >> > Just my two cents.
> > >> >> >
> > >> >> >
> > >> >> > Thank you && Regards, Jan
> > >> >> > --
> > >> >> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > >
> > >> >> > > I kind of know the answer :) But the team wanted to
ask.
> > >> >> > >
> > >> >> > > [1] -
https://www.keycloak.org/2019/04/versioning.html
> > >> >> > >
> > >> >> > > --
> > >> >> > > - abstractj
> > >> >> > > _______________________________________________
> > >> >> > > 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
> > >> >>
> > >> >
> > >> _______________________________________________
> > >> 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
>
10:50 a.m.
ok, perfect. Thanks for the clarification Stian
DAVID FFRENCH
Principal software engineer, CLOUD SERVICES
Red Hat Waterford <https://www.redhat.com/>
Communications House, Cork Road
Waterford, Ireland
dffrench(a)redhat.com
On Thu, Nov 7, 2019 at 3:54 PM Stian Thorgersen <sthorger(a)redhat.com> wrote:
On Thu, 7 Nov 2019 at 16:49, David Ffrench <dffrench(a)redhat.com> wrote:
> Thanks Stian. I would agree with the word support.
>
> So I think we are all in agreement that the Keycloak Operators initial
> version should be 7.x.x to match the version of Keycloak included. Follow
> on question, should it be exactly 7.0.1 to match the version of Keycloak
> included? What then happens if there is a new release needed for the
> operator but not keycloak itself. This would then mean an operator version
> 7.0.2 matches Keycloak version 7.0.1.
>
Our release process releases everything, so we would actually just do a
7.0.2 release if we needed an update to the operator. Most likely it would
be the other way around, as we'd probably always have something to fix in
Keycloak ;)
>
> One way around this to only align the major version of the operator to
> the major version of Keycloak and document what version of Keycloak is
> included.
>
> DAVID FFRENCH
>
> Principal software engineer, CLOUD SERVICES
>
> Red Hat Waterford <https://www.redhat.com/>
>
> Communications House, Cork Road
>
> Waterford, Ireland
>
> dffrench(a)redhat.com
>
>
>
>
>
> On Thu, Nov 7, 2019 at 1:28 PM Tomas Kyjovsky <tkyjovsk(a)redhat.com>
> wrote:
>
>>
>>
>> ----- Original Message -----
>> > On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)redhat.com> wrote:
>> >
>> > > So does that mean that RH-SSO 7.3.0.GA was based on Keycloak 4.8.3
>> and
>> > > RH-SSO 7.4.0 will be based on Keycloak 8.0.0? If we based our
>> Operator on
>> > > the Keycloak version (8.0.0) then the user wouldn't necessarily
know
>> what
>> > > RH-SSO version they would get (the operator can also install RH-SSO).
>> > >
>> >
>> > RH-SSO 7.4 will most likely be based on Keycloak 9.
>> >
>> >
>> > >
>> > > It sounds like we should base it on the RH-SSO version then, so the
>> > > Operator would be v7.4.0 which tells the user that they can either
>> get
>> > > RH-SSO 7.4.0.GA or Keycloak 8.0.0 from it.
>> > >
>> > > Does that make sense?
>> > >
>> >
>> > There should be two separate versions of the operator. One community
>> which
>> > will have version based on Keycloak, and another one for product, which
>> > should be based on RH-SSO versions. There is also a difference in
>> > maintenance/support for the Keycloak and the RH-SSO operator. The
>> Keycloak
>> > operator will be released together with Keycloak, with no micro updates
>> > (unless there are critical bugs or CVEs), while the RH-SSO release has
>> > micro releases for roughly a year.
>>
>> Since the versioning would be 1-1 would it make sense to develop the
>> operator directly as Keycloak project/product module?
>>
>> >
>> >
>> > >
>> > >
>> > >
>> > > On Wed, Nov 6, 2019 at 11:34 AM Stian Thorgersen <
>> sthorger(a)redhat.com>
>> > > wrote:
>> > >
>> > >> On Wed, 6 Nov 2019 at 10:10, David Ffrench
<dffrench(a)redhat.com>
>> wrote:
>> > >>
>> > >> > Hi Stian,
>> > >> >
>> > >> > I agree with your assessment since all other sub-components
within
>> > >> > Keycloak all use the same version. I would just like to
clarify
>> one
>> > >> point.
>> > >> >
>> > >> > have the version identical to Keycloak upstream, and identical
to
>> RH-SSO
>> > >> >> downstream
>> > >> >
>> > >> > I was under the impression these were on different versions.
>> Keycloak
>> > >> > 7.0.1 and RH-SSO 7.3.2? A follow on question, how long after
>> Keycloak
>> > >> 8.0.0
>> > >> > is release does the next version of RH-SSO get released and
will
>> this
>> > >> also
>> > >> > be 8.0.0?
>> > >> >
>> > >>
>> > >> Yes/no ;)
>> > >>
>> > >> RH-SSO has two versions. The product version (7.3.0.GA for
>> example) and
>> > >> the
>> > >> underlying productized Keycloak version (4.8.3.Final-redhat-0001).
>> RH-SSO
>> > >> 7.4.0.GA will be based on the latest Keycloak release at the time
>> (this
>> > >> will most likely be 8.0.0, so would be 8.0.0-redhat-0001). For
>> RH-SSO
>> > >> micro
>> > >> releases these are based on Keycloak micros (so RH-SSO 7.3.2 was
>> Keycloak
>> > >> 4.8.12 or something like that, can't remember the exact one).
As a
>> > >> side-note we don't do micro releases of older Keycloak versions
to
>> the
>> > >> community, so branches and releases of these are not available to
>> the
>> > >> public.
>> > >>
>> > >>
>> > >> >
>> > >> > Thanks
>> > >> >
>> > >> > DAVID FFRENCH
>> > >> >
>> > >> > Principal software engineer, CLOUD SERVICES
>> > >> >
>> > >> > Red Hat Waterford <https://www.redhat.com/>
>> > >> >
>> > >> > Communications House, Cork Road
>> > >> >
>> > >> > Waterford, Ireland
>> > >> >
>> > >> > dffrench(a)redhat.com
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <
>> slaskawi(a)redhat.com
>> > >> >
>> > >> > wrote:
>> > >> >
>> > >> >> Ok, you convinced me guys. Let's align it with
Keycloak.
>> > >> >>
>> > >> >> On Wed, Nov 6, 2019 at 9:08 AM Jan Lieskovsky <
>> jlieskov(a)redhat.com>
>> > >> >> wrote:
>> > >> >>
>> > >> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <
>> bruno(a)abstractj.org>
>> > >> >> wrote:
>> > >> >> >
>> > >> >> > > Good afternoon,
>> > >> >> > >
>> > >> >> > > During our stand-up meeting today we discussed
the
>> versioning of
>> > >> the
>> > >> >> > > new Keycloak Operator. In summary, if the
versioning should
>> follow
>> > >> the
>> > >> >> > > same scheme as semantic versioning, or follow
our continuous
>> > >> delivery
>> > >> >> > > model[1].
>> > >> >> > >
>> > >> >> > > The "old" Operator is actually on
1.9.4 and the new version
>> should
>> > >> be
>> > >> >> > > 2.0.0. But if we use our current versioning
scheme, that
>> means a
>> > >> >> > > significant bump, for example, 8.0.0.
>> > >> >> > >
>> > >> >> >
>> > >> >> > +1 for version of the operator being aligned with the
version
>> of
>> > >> other
>> > >> >> > components
>> > >> >> > (server, adapters etc.), even if this will mean:
>> > >> >> >
>> > >> >> > - Operator version will need initially to get
bumped
>> > >> substantially to
>> > >> >> > match the Keycloak server version,
>> > >> >> > - Operator would need to be released together with
other
>> > >> components
>> > >> >> this
>> > >> >> > way (IOW any, even possible urgent Operator fixes
would
>> need to
>> > >> wait
>> > >> >> for
>> > >> >> > N+1 server release).
>> > >> >> >
>> > >> >> > This makes more sense / is more consistent IMHO, than
keeping
>> the
>> > >> >> Operator
>> > >> >> > version as a separate one.
>> > >> >> > Besides that (as already mentioned) it removes the
need in the
>> future
>> > >> >> > (maybe often?) to clarify, which
>> > >> >> > Operator version matches which Keycloak server
version.
>> > >> >> >
>> > >> >> > Just my two cents.
>> > >> >> >
>> > >> >> >
>> > >> >> > Thank you && Regards, Jan
>> > >> >> > --
>> > >> >> > Jan iankko Lieskovsky / Keycloak / RH-SSO Team
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >> > >
>> > >> >> > > I kind of know the answer :) But the team wanted
to ask.
>> > >> >> > >
>> > >> >> > > [1] -
https://www.keycloak.org/2019/04/versioning.html
>> > >> >> > >
>> > >> >> > > --
>> > >> >> > > - abstractj
>> > >> >> > > _______________________________________________
>> > >> >> > > 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
>> > >> >>
>> > >> >
>> > >> _______________________________________________
>> > >> 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
>>
>
1877
days inactive
1879
days old
14 comments
8 participants
participants (8)
-
Bruno Oliveira -
David Ffrench -
Jan Lieskovsky -
Johnny Muczynski -
Peter Braun -
Sebastian Laskawiec -
Stian Thorgersen -
Tomas Kyjovsky