Adjusting the dependency implicitly has an effect on the import-version range being calculated by bnd for Sling bundles depending on Oak. Therefore depending on 1.7 most probably prevents the same Sling bundle from running with Oak 1.6. We had this discussion before and basically we were advised to only depend on the stable versions of Oak back then.
So I would much rather prefer to still rely on the last stable release. Konrad > On 11. Oct 2017, at 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 > >
