[keycloak-dev] Versioning - Keycloak Operator

[Stian Thorgersen]

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