On Wednesday 11 October 2017 12:15:25 Konrad Windszus wrote: > 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.
We should use releases from stable branches only, whether Oak or Jackrabbit or any other dependency. Regards, O. > 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
