[keycloak-dev] Versioning - Keycloak Operator

Thu Nov 7 11:50:05 EST 2019

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 at redhat.com

On Thu, Nov 7, 2019 at 3:54 PM Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On Thu, 7 Nov 2019 at 16:49, David Ffrench <dffrench at 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 at redhat.com
>>
>>
>>
>>
>>
>> On Thu, Nov 7, 2019 at 1:28 PM Tomas Kyjovsky <tkyjovsk at redhat.com>
>> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>> > On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun at 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 at redhat.com>
>>> > > wrote:
>>> > >
>>> > >> On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench at 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 at redhat.com
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> > On Wed, Nov 6, 2019 at 8:55 AM Sebastian Laskawiec <
>>> slaskawi at 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 at redhat.com>
>>> > >> >> wrote:
>>> > >> >>
>>> > >> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <
>>> bruno at 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 at lists.jboss.org
>>> > >> >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > >> >> > >
>>> > >> >> > _______________________________________________
>>> > >> >> > keycloak-dev mailing list
>>> > >> >> > keycloak-dev at lists.jboss.org
>>> > >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > >> >> >
>>> > >> >> _______________________________________________
>>> > >> >> keycloak-dev mailing list
>>> > >> >> keycloak-dev at lists.jboss.org
>>> > >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > >> >>
>>> > >> >
>>> > >> _______________________________________________
>>> > >> keycloak-dev mailing list
>>> > >> keycloak-dev at lists.jboss.org
>>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> > >>
>>> > >
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>