[keycloak-dev] Versioning - Keycloak Operator

Thu Nov 7 10:48:50 EST 2019

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