[keycloak-dev] Versioning - Keycloak Operator

Stian Thorgersen sthorger at redhat.com
Wed Nov 6 02:22:50 EST 2019


The simple approach is to release the operator together with all other bits
and bobs and have the version identical to Keycloak upstream, and identical
to RH-SSO downstream. Anything other than that needs more discussion and
consideration.

To add a bit more context. Today we release Keycloak server, Java adapters,
Node.js adapter and Gatekeeper, all with the same version. This simplifies
the release process both for upstream and downstream. It also simplifies
documentation as there is a single version to worry about. Doing different
release cadence for different bits may have some benefits, but would be a
fair amount of work upfront and would also add overhead on a
release-by-release basis.

For semver. We don't follow semver. We aim a continuous model where we have
deprecation of features, rather than major breaking changes.

With regards to compatibility the simplest would be to require
matching versions of operator and software. Anything else would need
documenting compatibility as well as testing a matrix of versions together.

On Tue, 5 Nov 2019 at 20:25, Johnny Muczynski <jmuczynski at simuquest.com>
wrote:

> re: version numbers
> Users of the software will want to know which version of X is compatible
> with which version of Y.
> This seems very relevant to an operator.
> One way of doing this is by keeping the major version numbers matching when
> the software has compatibility.
>
> Kind regards,
> Johnny
>
> --
> Johnny Muczynski
> SimuQuest, Inc.
> 35 Research Dr. Ste 400
> Ann Arbor, MI 48103
> cell: 734-262-2045
>
>
> On Tue, Nov 5, 2019 at 2:04 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.
> >
> > 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
>


More information about the keycloak-dev mailing list