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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Konrad Windszus-2
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
Reply | Threaded
Open this post in threaded view
|

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

Julian Sedding-3
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
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Julian Sedding-3
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 <[hidden email]> 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
> <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Konrad Windszus
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 <[hidden email]>:
>
> 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 <[hidden email]> 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
>> <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Bertrand Delacretaz
On Sat, Nov 26, 2016 at 5:18 PM, Konrad Windszus <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Felix Meschberger-3
In reply to this post by Konrad Windszus
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 <[hidden email]>:
>
> 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 <[hidden email]>:
>>
>> 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 <[hidden email]> 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
>>> <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

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

Konrad Windszus
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 <[hidden email]> 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 <[hidden email]>:
>>
>> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]> 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
>>>> <[hidden email]> 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
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Julian Sedding-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]>:
>>>>
>>>> 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 <[hidden email]> 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
>>>>> <[hidden email]> 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
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

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

Felix Meschberger-3
In reply to this post by Konrad Windszus

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

Reply | Threaded
Open this post in threaded view
|

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

Bertrand Delacretaz
In reply to this post by Konrad Windszus
On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Konrad Windszus
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 <[hidden email]> wrote:
>
> On Mon, Nov 28, 2016 at 9:50 AM, Konrad Windszus <[hidden email]> 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