[keycloak-dev] Policy around migration-*.cli scripts

[Stian Thorgersen]

Stan knows this stuff better than anyone, but I seem to remember there was
some good reasons for this.

On 14 September 2017 at 18:28, Marko Strukelj <mstrukel at redhat.com> wrote:

> I was wondering why migration-*.cli scripts contain migrations for
> keycloak-server subsystem.
>
> It makes perfect sense that they are used to adjust configuration of other
> wildfly subsystems that we don't control. But for keycloak-server I imagine
> all migration should be performed at runtime by keycloak-server subsystem
> itself. This way migration is easier to do, it involves fewer modules in
> our build, fewer files (no /subsystem=keycloak-server entries in
> migration-*.cli files), and it's testable in a single module.
>
> Any reason why not do it that way?
>
> Another thing - currently our (de facto) versioning policy for keycloak
> subsystems is to not increment the version as long as the old syntax/model
> keeps working, even if we introduce new xml syntax we keep the old version
> number.
>
> In practice that means that if I see an example of subsystem configuration
> somewhere, and I copy it to the older version of Keycloak (why not, it says
> it's still version 1.1) that would not work if it contains any later syntax
> that older version doesn't understand. Older keycloak-server configuration
> can be copied to newer version of Keycloak without issues.
>
> That's simple for us to maintain, and seems to work well enough.
> Technically we'll only have to increment version if we decide to break
> backwards compatibility of the configuration - nowhere on our radar ATM.
>
> Does anyone see this policy as problematic?
>
> - marko
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>