Having said that, the only bullet to bite when switching to Oak 1.7.x is increased maintenance effort: the affected bundles will become backwards incompatible wrt Oak 1.6.x and if they need to be patched it would not be possible to do so in trunk anymore.
Cheers, Stefan On 11/10/17 12:03, "Stefan Egli" <stefane...@apache.org> wrote: >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" <ianbos...@gmail.com on behalf of >i...@tfd.co.uk> 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 > >
