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
>