You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Konrad Windszus <ko...@netcentric.biz> on 2016/11/25 17:34:50 UTC
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 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
Re: How to handle minor version updates in API for provider bundles?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Nov 26, 2016 at 5:18 PM, Konrad Windszus <ko...@gmx.de> 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 consumers to specify
> a minimal version of that package (in case they rely on the new semantics of those methods)...
+1 and also +1 to avoid exposing new methods unless absolutely needed.
-Bertrand
Re: How to handle minor version updates in API for provider bundles?
Posted by Felix Meschberger <fm...@adobe.com>.
> Am 28.11.2016 um 09:50 schrieb Konrad Windszus <ko...@gmx.de>:
> @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 <fm...@adobe.com> 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 <ko...@gmx.de>:
>>>
>>> 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 <js...@gmail.com>:
>>>>
>>>> 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 <js...@gmail.com> 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
>>>>> <ko...@netcentric.biz> 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
>>>
>>
>
Re: How to handle minor version updates in API for provider bundles?
Posted by Julian Sedding <js...@gmail.com>.
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 <ko...@gmx.de> 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 <fm...@adobe.com> 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 <ko...@gmx.de>:
>>>
>>> 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 <js...@gmail.com>:
>>>>
>>>> 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 <js...@gmail.com> 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
>>>>> <ko...@netcentric.biz> 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
>>>
>>
>
Re: How to handle minor version updates in API for provider bundles?
Posted by Konrad Windszus <ko...@gmx.de>.
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 <bd...@apache.org> wrote:
>
> On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus <ko...@gmx.de> 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 that demonstrate the new behavior?
>
> -Bertrand
Re: How to handle minor version updates in API for provider bundles?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus <ko...@gmx.de> 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 that demonstrate the new behavior?
-Bertrand
Re: How to handle minor version updates in API for provider bundles?
Posted by Konrad Windszus <ko...@gmx.de>.
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 <fm...@adobe.com> 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 <ko...@gmx.de>:
>>
>> 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 <js...@gmail.com>:
>>>
>>> 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 <js...@gmail.com> 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
>>>> <ko...@netcentric.biz> 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
>>
>
Re: How to handle minor version updates in API for provider bundles?
Posted by Felix Meschberger <fm...@adobe.com>.
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 <ko...@gmx.de>:
>
> 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 <js...@gmail.com>:
>>
>> 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 <js...@gmail.com> 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
>>> <ko...@netcentric.biz> 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
>
Re: How to handle minor version updates in API for provider bundles?
Posted by Konrad Windszus <ko...@gmx.de>.
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 <js...@gmail.com>:
>
> 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 <js...@gmail.com> 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
>> <ko...@netcentric.biz> 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
Re: How to handle minor version updates in API for provider bundles?
Posted by Julian Sedding <js...@gmail.com>.
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 <js...@gmail.com> 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
> <ko...@netcentric.biz> 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
Re: How to handle minor version updates in API for provider bundles?
Posted by Julian Sedding <js...@gmail.com>.
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
<ko...@netcentric.biz> 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