Thanks Konrad for moving the implementation. As I understand this issue, we *clarify* the semantics of RR.isResourceType and fix the implementation to be fully aligned with the fully defined semantics.
AFAIU, Konrad reported the issue, because the impl didn't match his expectations. Bertrand and I agreed with this perception. So I am not sure if we require a minor version increment or not. I believe an equally valid argument could be made for either case - changed semantics and implementation OR clarified semantics and fixed implementation. I guess it boils down to a semantic difference ;) I would lean towards no minor version increment, but have no strong feelings either way. Regards Julian On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus <[email protected]> wrote: > I moved the new util methods regarding the resource type comparison to a > private util class into the resource resolver bundle (in r1771688). > The package version change still is necessary IMHO. > > @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. > 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 >>> >> >
