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
>