Re: [keycloak-dev] Versioning - Keycloak Operator

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(a)redhat.com On Thu, Nov 7, 2019 at 1:28 PM Tomas Kyjovsky <tkyjovsk(a)redhat.com&gt; wrote: > > > ----- Original Message ----- > > On Wed, 6 Nov 2019 at 11:51, Peter Braun <pbraun(a)redhat.com&gt; 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(a)redhat.com > > > > > wrote: > > > > > >> 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 > > >> > > > >> > 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 > > >> > > > > > _______________________________________________ > > 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 >