Can’t we stay BC and just introduce a new command that has the new behavior and keep the old one as is?
Something like: DELETE REAL USER or similar would be consistent with the service user delete at least. It seems like a lot of hazel down the line to break the language and introduce a version management just because of this issue. Just introduce new command(s) and keep the old one(s) around (potentially with a warn) seems nicer to me. regards, Karl On Tuesday, October 2, 2018, Carsten Ziegeler <[email protected]> wrote: > 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] > -- Karl Pauls [email protected]
