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

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev