How to manage repoinit language + implementation evolutions?

[Bertrand Delacretaz <bd...@apache.org>]

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

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?

-Bertrand