Hi Ian, I don't see a problem with having a dependency on an unstable Oak 1.7.x in Sling.
Actual deployments can still, independent of this, make a call whether or not they want to actually run on Oak 1.7.x or wait for Oak 1.8 (which is advisable). IMO having this dependency doesn't imply on which version it will ultimately run. Cheers, Stefan On 11/10/17 11:54, "Ian Boston" <[email protected] on behalf of [email protected]> wrote: >Hi, >Oak 1.7.x is Oak unstable release branch working towards 1.8. >I have a feature in SLING-7140 that is blocked by an API change in Oak >present in 1.8-SNAPSHOT and available as an unmerged but tested patch to >Oak 1.6.x. > >The Oak team are unwilling merge the patch to 1.6 and have asked that >Sling >depend on the latest release of Oak 1.7. > >How does the Sling team feel about this ? > >The patch for SLING-7140 cant be merged until the API is available in Oak >in some form and I don't want to depend on Oak 1.8-SNAPSHOT as this will >block Sling releases of the bundles involved. >Best Regards >Ian
