Bertrand Delacretaz wrote: > Hi, > > We have a concrete case in SLING-7960 where a repoinit bug needs > fixing in a way that won't be fully compatible with the existing > implementation. > The difference is minor but still means it's a good time to define > how we'll handle language evolutions. > The problem is that the DELETE USER statement currently also deletes > system users, and that's wrong considering that there is also a DELETE > SERVICE USER statement. So fixing that bug will change the behavior of > existing repoinit scripts that use those statements. Here's a > suggestion on how to handle this evolution, by optionally marking > repoinit scripts to require a specific language + implementation > version. I think those should be expressed as OSGi capabilities. > > 1) Repoinit scripts can optionally include a statement like > REQUIRE VERSION language=1.0, jcr=1.2 Why do we need two things here (version and jcr)?
> 2) If that statement is not included, versions default to the > currently released ones, before the SLING-7960 bug fix. > 3) Java code that executes the repoinit statements is made aware of > those versions > 4) For the SLING-7960 code, the behavior is how it was before fixing > this bug, unless REQUIRE VERSION points to a newer jcr module > version This is just initial ideas, what do people think? I guess this could work, however, there is one important additional thing to consider. Today you can concatenate several repoinit statement blocks to create one large repoinit instruction set. This is done by all the tooling around repoinit, provisioning model, feature model etc. With a optional version statement at the top, simply chaining repoinit blocks is not possible anymore. The tooling would need to check whether a version statement is there, if not put one there for our first version. And the parser would need to accept version statements anywhere in the repoinit text where that version is then used for all following statements until another version is mentioned Regards Carsten > -Bertrand -- Carsten Ziegeler Adobe Research Switzerland [email protected]
