Re: How to handle minor version updates in API for provider bundles?

Yes, I did, just look at the mentioned commits in ticket https://issues.apache.org/jira/browse/SLING-6327. Konrad > On 28 Nov 2016, at 10:14, Bertrand Delacretaz wrote: > > On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus wrote: >> ...There were no

Re: How to handle minor version updates in API for provider bundles?

On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus wrote: > ...There were no tests which had to be adjusted for the change, but in fact > there is a semantical change... hmm...hmm...hmm...that vague feeling that the test coverage is not what it should be ;-) Did you add tests

Re: How to handle minor version updates in API for provider bundles?

> Am 28.11.2016 um 09:50 schrieb Konrad Windszus : > @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

Re: How to handle minor version updates in API for provider bundles?

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

Re: How to handle minor version updates in API for provider bundles?

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

Re: How to handle minor version updates in API for provider bundles?

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 : > > Moving the Util methods somewhere else (and even making that Util private) is > fine with me,

Re: How to handle minor version updates in API for provider bundles?

On Sat, Nov 26, 2016 at 5:18 PM, Konrad Windszus wrote: > ...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

Re: How to handle minor version updates in API for provider bundles?

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

Re: How to handle minor version updates in API for provider bundles?

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

Re: How to handle minor version updates in API for provider bundles?

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

How to handle minor version updates in API for provider bundles?

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