> Am 28.11.2016 um 09:50 schrieb Konrad Windszus <[email protected]>: > @Felix: Regarding backwards compatibility: There were not tests which had to > be adjusted for the change, but in fact there is a semantical change. Please > look at https://issues.apache.org/jira/browse/SLING-6327 for further details.
Ok, technically it looks like it is breaking. But I have the impression, this makes sense and is more consistent with RR.getResource. Thanks Felix > Konrad > >> On 28 Nov 2016, at 09:42, Felix Meschberger <[email protected]> wrote: >> >> Hi Konrad >> >> Hmm, are these changed semantics backwards compatible ? >> >> I.e. what do existing callers have to expect ? >> >> Regards >> Felix >> >>> Am 26.11.2016 um 17:18 schrieb Konrad Windszus <[email protected]>: >>> >>> Moving the Util methods somewhere else (and even making that Util private) >>> is fine with me, but would not change anything about the minor version >>> number increase in the o.a.s.resource package. >>> With the change in SLING-6327 the behaviour of Resource.isResourceType and >>> ResourceResolver.isResourceType has been changed (semantically) and >>> therefore requires at least a minor version upgrade to allow consumers to >>> specify a minimal version of that package (in case they rely on the new >>> semantics of those methods). >>> Konrad >>> >>>> Am 26.11.2016 um 16:17 schrieb Julian Sedding <[email protected]>: >>>> >>>> Thinking about this some more. I don't think the added method is >>>> generally useful for an API user, because the search-paths are >>>> normally not available. So I could imagine creating a ResourceTypeUtil >>>> class in the resourceresolver project to hold these new methods. We >>>> would thus not touch the Sling API and the utility could start out in >>>> a private package until we identify other places where we would need >>>> it. >>>> >>>> WDYT? >>>> >>>> Regards >>>> Julian >>>> >>>> >>>> On Fri, Nov 25, 2016 at 6:51 PM, Julian Sedding <[email protected]> wrote: >>>>> I think the core problem is that we have provider-type classes and >>>>> consumer-type classes mixed in packages of sling.api. Maybe we should >>>>> start thinking about how to improve the situation there? >>>>> >>>>> For now, I think what we normally do is update everything to snapshots >>>>> that needs it and then start releasing. >>>>> >>>>> Alternatively, we could stick with the lower dependency and duplicate >>>>> the method you added until we want to update everything to the new >>>>> api. >>>>> >>>>> Regards >>>>> Julian >>>>> >>>>> On Fri, Nov 25, 2016 at 6:34 PM, Konrad Windszus >>>>> <[email protected]> wrote: >>>>>> With https://issues.apache.org/jira/browse/SLING-6327 I increased the >>>>>> minor version of o.a.s.resource from 2.9.0 to 2.10.0 (because of added >>>>>> methods to a ResourceUtil). That means that all provider bundles for >>>>>> this package (namely o.a.s.jcr.resource and o.a.s.resourceresolver) need >>>>>> to be recompiled with an updated dependency to the latest API snapshot, >>>>>> to make the latest SNAPSHOTs of all bundles compatible with each other >>>>>> (and generate the correct import-package version range in the provider >>>>>> bundles). >>>>>> What is the suggested approach for doing that? >>>>>> Just increase the dependency to the latest API snapshot again in all >>>>>> provider bundles for the according packages (although this will be >>>>>> prevent those provider bundles from being easily releasable, because API >>>>>> would need to be released first) or are there any other suggestions? >>>>>> Thanks, >>>>>> Konrad >>> >> >
