Re: [keycloak-dev] Versioning - Keycloak Operator

On Wed, 6 Nov 2019 at 10:10, David Ffrench <dffrench(a)redhat.com&gt; 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&gt; > 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&gt; >> wrote: >> >> > On Tue, Nov 5, 2019 at 8:02 PM Bruno Oliveira <bruno(a)abstractj.org&gt; >> 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