I share Julians concerns. In a private conversation Marcel suggested to reconsider placing the new API into oak-api and put it to Jackrabbit API instead. If there is really no Oak dependency in there that would make a lot of sense to me. In particular since the Sling community used to be quite strict about any kind of implementation dependency to Jackrabbit/Oak and only want to depend on JCR... Jackrabbit API is the natural extension of JCR, where as Oak API is on a different layer in the stack and from a Sling PoV a implementation detail of a JCR implementation.
So, I would opt for taking following up on Marcels suggestion. Kind regards Angela On 13/10/17 17:22, "Julian Reschke" <[email protected]> wrote: >On 2017-10-13 17:02, Ian Boston wrote: >> Hi, >> Thank you for the clarification. It sounds like Sling can't safely bind >>to >> 1.7.x and safely make releases that will not cause problems with package >> versions later. That blocks Sling from binding to any features not >> backported to a stable version of Oak. > >That blocks Sling from *releasing* something as stable which relies on >an unstable Oak feature. > >As far as I can tell, it doesn't mean that Sling can't experiment with >it, and even make experimental releases for Sling's downstream users. > >> The (obvious) reason for asking was I still need to get OAK-6575 into >> Sling. Since that wont be possible til 1.8 is released could the 1.6 >> backport patch I did for 1.6 be reconsidered ? > >I understand your pain, but forcing something into a stable release of >Oak just because Sling's release model is incompatible with Oak's makes >me really uncomfortable. > >Best regards, Julian >
