Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Tim Ward via osgi-dev]

Michael, 

I promise that we are trying to help, but there’s clearly quite a bit of 
confusion here. I’ll try to take the questions individually, and we can attempt 
to separate your questions about build/packaging (i.e. creating your bundle) 
and resolving (i.e. creating your deployment). These are two very separate 
steps.


> There aren't any more details. I was seeing a resolver result that included 
> bundle A-2.0.1 (which exports packages with version 2.0.1) although there was 
> another bundle in the same result set that had Import-Package statements with 
> versions [2.0.3,3) for the packages provided by bundle A.
> 
Ok, did the resolve result also include A-2.0.3, or perhaps some other bundle 
else providing the package A in the range [2.0.3,3)? 

If not then this is a serious bug because the resolver should never return an 
“invalid” result (i.e. one which can’t resolve when installed in an OSGi 
framework). The only way that B will resolve is if someone provides the package 
A in the range [2.0.3,3).

If the resolve result *did* also include A-2.0.3 then the question is why did 
it *also* include A-2.0.1 - there could be a lot of reasons for this, some of 
which mean that it *must* be deployed (some other else with a tight micro range 
on its import). Failing that we do our best to avoid duplication (of symbolic 
name) in the results, but the resolution process is complex and it can be hard 
to eliminate valid (i.e. it would deploy and resolve) but “unexpected” (it 
doesn’t contain what you think it should, or contains more than you think it 
should) results. In these cases it’s usually best to make sure that stuff you 
don’t want to deploy is removed from your repository, which makes it impossible 
for the resolver to pick them.

> I wondered whether this was to be expected or a bug.
> 

That really depends on the specifics of what you saw. If deploying the resolved 
list of bundles into a framework fails to resolve then it is definitely a bug. 
Most (but not all) of the other options boil down to errors in usage, the fact 
that the application really does need the extra bundle (despite what you may 
believe), or more rarely (because this is tested and used quite a lot) bugs in 
the resolver.

The only way we can be sure which of these scenarios is happening is to see the 
repository and the bndrun. This is why we keep asking if you can show them to 
us so we can help to work out whether what you’re seeing is “correct”, “correct 
but suboptimal”, or just plain “wrong”.

> If I know some bundle (one of its exported packages to be precise) to be 
> buggy up to (and including) version x.y.z then why should I not explicitly 
> reference x.y.z+1 (i.e. the first fixed version) as a requirement for the 
> Import-Package?
> 
You absolutely can have a dependency on a micro version, but this isn’t a 
resolver issue, it’s a build/packaging issue. That’s the point at which you 
define the version range for your import package. If you know that you need a 
specific bug fix package then by all means put that as your base version. The 
recommendation to avoid micro versions in the import range still applies though 
as tight restrictions limit deployment flexibility. You obviously understand 
this on some level because you haven’t been trying to limit the upper version 
to A-2.0.4, but instead to A-3.
> Why doesn't it make sense to deploy the latest bug fix all the time? Why 
> should I deploy an older version that is known to show bugs?
> 

As Peter said back down the mail chain, it makes sense to *compile* against the 
lowest version that will work and *deploy* the highest version that will work. 
This ensures that your bundles will work in the maximum number of deployment 
scenarios, while still getting the bug fixes.

I haven’t seen anyone say that you shouldn’t be deploying the latest bug fix, 
and the bnd resolver prefers higher versions over lower versions where it has a 
choice. 

I hope this helps,

Tim


> On 18 Jun 2019, at 16:17, Michael Lipp via osgi-dev  
> wrote:
> 
> 
>>  
>> Can we please step back to the beginning and describe, in much more detail, 
>> the issue you are seeing? I never understood the actual issue you seemed to 
>> be having.
> There aren't any more details. I was seeing a resolver result that included 
> bundle A-2.0.1 (which exports packages with version 2.0.1) although there was 
> another bundle in the same result set that had Import-Package statements with 
> versions [2.0.3,3) for the packages provided by bundle A.
> 
> I wondered whether this was to be expected or a bug. The resolver process 
> description in the spec says "The importer's version range matches the 
> exporter's version. See Semantic Versioning 
> ."
>  
> [https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess
>  
> 

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Michael Lipp via osgi-dev]

>  
> Can we please step back to the beginning and describe, in much more
> detail, the issue you are seeing? I never understood the actual issue
> you seemed to be having.

There aren't any more details. I was seeing a resolver result that
included bundle A-2.0.1 (which exports packages with version 2.0.1)
although there was another bundle in the same result set that had
Import-Package statements with versions [2.0.3,3) for the packages
provided by bundle A.

I wondered whether this was to be expected or a bug. The resolver
process description in the spec says "The importer's version range
matches the exporter's version. See Semantic Versioning
."
[https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess]
In the section referenced I found "It is recommended to ignore the micro
part of the version because systems tend to become very rigid if they
require the latest bug fix to be deployed all the time." I still don't
understand this recommendation and would be grateful for an explanation.
If I know some bundle (one of its exported packages to be precise) to be
buggy up to (and including) version x.y.z then why should I not
explicitly reference x.y.z+1 (i.e. the first fixed version) as a
requirement for the Import-Package? Why doesn't it make sense to deploy
the latest bug fix all the time? Why should I deploy an older version
that is known to show bugs?

 - Michael


>  
>  
> --
>
> BJ Hargrave
> Senior Technical Staff Member, IBM // office: +1 386 848 1781
> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> hargr...@us.ibm.com
>  
>  
>
> - Original message -
> From: Michael Lipp via osgi-dev 
> Sent by: osgi-dev-boun...@mail.osgi.org
> To: Neil Bartlett , OSGi Developer Mail List
> 
> Cc:
> Subject: [EXTERNAL] Re: [osgi-dev] Micro version ignored when
> resolving, rationale?
> Date: Tue, Jun 18, 2019 09:33
>  
>  
>> As for why bnd makes this implementation choice, bear in mind
>> that import ranges are applied to packages, which in a pure and
>> ideal world would contain only interfaces and perhaps DTOs, but
>> no implementation code. What kind of "bugs" could we be talking
>> about in such a package, other than documentation? Of course the
>> world is not always pure and ideal which is why the default can
>> be overridden.
>
> But in the real world, every project imports "OSGi-fied"
> libraries, usually several, and they have bugs and (hopefully)
> fixes. So it is something to be considered. What good is a tool
> that works in an ideal world if you need something done in the
> real world.
>
>  - Michael
>
>>  
>> Neil
>>  
>>  
>>  
>> On Tue, 18 Jun 2019 at 09:54, Michael Lipp via osgi-dev
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>>
>>  

 Considering this, lowering a lower bound of an
 Import-Package statement when resolving should be
 acknowledged as a bug. 

>>> I beg to differ ...
>>>
>>> As said, you can set the consumer/provider policy to your
>>> desired strategy.
>>>
>> So having default settings in the tool that cause a behavior
>> that does not comply with the specification should not be
>> considered a bug?
>>
>>  - Michael
>>
>>  
>>
>>>  
>>> Kind regards,
>>>  
>>> Peter Kriens
>>>  
 On 18 Jun 2019, at 10:33, Michael Lipp >>> > wrote:
  
  
>  
> I expect there are two things at play. First, OSGi
> specifies things as you indicate. An import of
> [1.2.3.qualifier,2) must not select anything lower than
> 1.2.3.qualifier. Second, bnd does have heuristics that do
> drop the qualifier and micro part in calculating the
> import ranges from the exports on the class path.

 Thanks for the clarification, I think this explains things.

> [...]
>  
> Conclusion, the spec is perfect but the implementations
> apply heuristics and may have bugs.

 The specification says (or defines, if you like): "|micro|
 - A change that does not affect the API, for example, a
 typo in a comment or a bug fix in an implementation." It
 explicitly invites the developer to indicate a bug fix by
 incrementing the micro part. There's no hint or requirement
 that he should increment the minor part to reflect a bug
 fix. I do not find your statement "The definition of the
 micro version is that it should not make a difference in
 runtime" to be 

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[BJ Hargrave via osgi-dev]

Michael,
 
Can we please step back to the beginning and describe, in much more detail, the issue you are seeing? I never understood the actual issue you seemed to be having.
 
 
--BJ HargraveSenior Technical Staff Member, IBM // office: +1 386 848 1781OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788hargr...@us.ibm.com
 
 
- Original message -From: Michael Lipp via osgi-dev Sent by: osgi-dev-boun...@mail.osgi.orgTo: Neil Bartlett , OSGi Developer Mail List Cc:Subject: [EXTERNAL] Re: [osgi-dev] Micro version ignored when resolving, rationale?Date: Tue, Jun 18, 2019 09:33 
 

As for why bnd makes this implementation choice, bear in mind that import ranges are applied to packages, which in a pure and ideal world would contain only interfaces and perhaps DTOs, but no implementation code. What kind of "bugs" could we be talking about in such a package, other than documentation? Of course the world is not always pure and ideal which is why the default can be overridden.
But in the real world, every project imports "OSGi-fied" libraries, usually several, and they have bugs and (hopefully) fixes. So it is something to be considered. What good is a tool that works in an ideal world if you need something done in the real world.
 - Michael
 
Neil
 
  

On Tue, 18 Jun 2019 at 09:54, Michael Lipp via osgi-dev  wrote:
 
Considering this, lowering a lower bound of an Import-Package statement when resolving should be acknowledged as a bug. 
I beg to differ ...
As said, you can set the consumer/provider policy to your desired strategy.
So having default settings in the tool that cause a behavior that does not comply with the specification should not be considered a bug?
 - Michael
 
 
Kind regards,
 
Peter Kriens
 
On 18 Jun 2019, at 10:33, Michael Lipp  wrote: 

 
 
I expect there are two things at play. First, OSGi specifies things as you indicate. An import of [1.2.3.qualifier,2) must not select anything lower than 1.2.3.qualifier. Second, bnd does have heuristics that do drop the qualifier and micro part in calculating the import ranges from the exports on the class path.
Thanks for the clarification, I think this explains things.
[...]
 Conclusion, the spec is perfect but the implementations apply heuristics and may have bugs.
The specification says (or defines, if you like): "micro - A change that does not affect the API, for example, a typo in a comment or a bug fix in an implementation." It explicitly invites the developer to indicate a bug fix by incrementing the micro part. There's no hint or requirement that he should increment the minor part to reflect a bug fix. I do not find your statement "The definition of the micro version is that it should not make a difference in runtime" to be supported by the spec or the Semantic Versioning Whitepaper. Actually, this interpretation would restrict the usage of the micro part to documentation changes because every bug fix changes the runtime behavior. This is, after all, what it is intended to do.
Considering this, lowering a lower bound of an Import-Package statement when resolving should be acknowledged as a bug.
 - Michael
 
 
Kind regards,
 
Peter Kriens
 
On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev  wrote: 

Hi,I have in my repository a bundle A-2.0.1 that exports packages withversion 2.0.1 and a bundle A-2.0.3 that exports these packages withversion 2.0.3. Version A-2.0.3 fixes a bug.I have a bundle B that imports the packages from A with importstatements "... version=[2.0.3,3)" because the bug fix is crucial forthe proper working of B.Clicking on "Resolve" in bndtools, I get a resolution with bundleA-2.0.1. I understand that this complies with the specification ("It isrecommended to ignore the micro part of the version because systems tendto become very rigid if they require the latest bug fix to be deployedall the time.").What I don't understand is the rationale. I don't see any drawbacks indeploying the latest bug fix. Of course, there's always the risk ofintroducing a new bug with a new version, even if it is supposed to onlyfix a bug in the previous version. But if you're afraid of this, you mayalso not allow imports with version ranges such as "[1.0,2)" (forconsumers).In my case, I now have to distribute bundle B with a release note toconfigure the resolution in such a way that only A 2.0.3 and up is used.Something that you would expect to happen automatically looking at theimport statement. And if I want to make sure that the release note isnot overlooked, the only way seems to be to check the version of "A" atrun-time in the activation of "B". This is downright ugly. - Michael___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
 
 ___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev
 

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Michael Lipp via osgi-dev]

> As for why bnd makes this implementation choice, bear in mind that
> import ranges are applied to packages, which in a pure and ideal world
> would contain only interfaces and perhaps DTOs, but no implementation
> code. What kind of "bugs" could we be talking about in such a package,
> other than documentation? Of course the world is not always pure and
> ideal which is why the default can be overridden.

But in the real world, every project imports "OSGi-fied" libraries,
usually several, and they have bugs and (hopefully) fixes. So it is
something to be considered. What good is a tool that works in an ideal
world if you need something done in the real world.

 - Michael

>
> Neil
>
>
>
> On Tue, 18 Jun 2019 at 09:54, Michael Lipp via osgi-dev
> mailto:osgi-dev@mail.osgi.org>> wrote:
>
>
>>> Considering this, lowering a lower bound of an Import-Package
>>> statement when resolving should be acknowledged as a bug. 
>>>
>> I beg to differ ...
>>
>> As said, you can set the consumer/provider policy to your desired
>> strategy.
>>
> So having default settings in the tool that cause a behavior that
> does not comply with the specification should not be considered a bug?
>
>  - Michael
>
>
>>
>> Kind regards,
>>
>> Peter Kriens
>>
>>> On 18 Jun 2019, at 10:33, Michael Lipp >> > wrote:
>>>
>>>

 I expect there are two things at play. First, OSGi specifies
 things as you indicate. An import of [1.2.3.qualifier,2) must
 not select anything lower than 1.2.3.qualifier. Second, bnd
 does have heuristics that do drop the qualifier and micro part
 in calculating the import ranges from the exports on the class
 path.
>>>
>>> Thanks for the clarification, I think this explains things.
>>>
 [...]

 Conclusion, the spec is perfect but the implementations apply
 heuristics and may have bugs.
>>>
>>> The specification says (or defines, if you like): "|micro| - A
>>> change that does not affect the API, for example, a typo in a
>>> comment or a bug fix in an implementation." It explicitly
>>> invites the developer to indicate a bug fix by incrementing the
>>> micro part. There's no hint or requirement that he should
>>> increment the minor part to reflect a bug fix. I do not find
>>> your statement "The definition of the micro version is that it
>>> should not make a difference in runtime" to be supported by the
>>> spec or the Semantic Versioning Whitepaper. Actually, this
>>> interpretation would restrict the usage of the micro part to
>>> documentation changes because every bug fix changes the runtime
>>> behavior. This is, after all, what it is intended to do.
>>>
>>> Considering this, lowering a lower bound of an Import-Package
>>> statement when resolving should be acknowledged as a bug.
>>>
>>>  - Michael
>>>
>>>

 Kind regards,

 Peter Kriens

> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev
> mailto:osgi-dev@mail.osgi.org>> wrote:
>
> Hi,
>
> I have in my repository a bundle A-2.0.1 that exports packages
> with
> version 2.0.1 and a bundle A-2.0.3 that exports these packages
> with
> version 2.0.3. Version A-2.0.3 fixes a bug.
>
> I have a bundle B that imports the packages from A with import
> statements "... version=[2.0.3,3)" because the bug fix is
> crucial for
> the proper working of B.
>
> Clicking on "Resolve" in bndtools, I get a resolution with bundle
> A-2.0.1. I understand that this complies with the
> specification ("It is
> recommended to ignore the micro part of the version because
> systems tend
> to become very rigid if they require the latest bug fix to be
> deployed
> all the time.").
>
> What I don't understand is the rationale. I don't see any
> drawbacks in
> deploying the latest bug fix. Of course, there's always the
> risk of
> introducing a new bug with a new version, even if it is
> supposed to only
> fix a bug in the previous version. But if you're afraid of
> this, you may
> also not allow imports with version ranges such as "[1.0,2)" (for
> consumers).
>
> In my case, I now have to distribute bundle B with a release
> note to
> configure the resolution in such a way that only A 2.0.3 and
> up is used.
> Something that you would expect to happen automatically
> looking at the
> import statement. And if I want to make sure that the release
> note is
> not overlooked, the only way seems to be to check the version
> of "A" at
> run-time in the activation of "B". This is downright ugly.
>
>  - 

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Neil Bartlett via osgi-dev]

> So having default settings in the tool that cause a behavior that does
not comply with the specification should not be considered a bug?

Which specification?? There is NO specification in OSGi for how a packaging
tool such as bnd should generate bundles from Java classes and descriptors.
The default import range is an implementation choice of the bnd developers.

All functionality that is specced by OSGi here -- i.e. the resolving of the
bundles -- is working perfectly according to the relevant OSGi
specification.

As for why bnd makes this implementation choice, bear in mind that import
ranges are applied to packages, which in a pure and ideal world would
contain only interfaces and perhaps DTOs, but no implementation code. What
kind of "bugs" could we be talking about in such a package, other than
documentation? Of course the world is not always pure and ideal which is
why the default can be overridden.

Neil



On Tue, 18 Jun 2019 at 09:54, Michael Lipp via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

>
> Considering this, lowering a lower bound of an Import-Package statement
> when resolving should be acknowledged as a bug.
>
> I beg to differ ...
>
> As said, you can set the consumer/provider policy to your desired strategy.
>
> So having default settings in the tool that cause a behavior that does not
> comply with the specification should not be considered a bug?
>
>  - Michael
>
>
>
> Kind regards,
>
> Peter Kriens
>
> On 18 Jun 2019, at 10:33, Michael Lipp  wrote:
>
>
>
> I expect there are two things at play. First, OSGi specifies things as you
> indicate. An import of [1.2.3.qualifier,2) must not select anything lower
> than 1.2.3.qualifier. Second, bnd does have heuristics that do drop the
> qualifier and micro part in calculating the import ranges from the exports
> on the class path.
>
> Thanks for the clarification, I think this explains things.
>
> [...]
>
> Conclusion, the spec is perfect but the implementations apply heuristics
> and may have bugs.
>
> The specification says (or defines, if you like): "micro - A change that
> does not affect the API, for example, a typo in a comment or a bug fix in
> an implementation." It explicitly invites the developer to indicate a bug
> fix by incrementing the micro part. There's no hint or requirement that he
> should increment the minor part to reflect a bug fix. I do not find your
> statement "The definition of the micro version is that it should not make a
> difference in runtime" to be supported by the spec or the Semantic
> Versioning Whitepaper. Actually, this interpretation would restrict the
> usage of the micro part to documentation changes because every bug fix
> changes the runtime behavior. This is, after all, what it is intended to do.
>
> Considering this, lowering a lower bound of an Import-Package statement
> when resolving should be acknowledged as a bug.
>
>  - Michael
>
>
>
> Kind regards,
>
> Peter Kriens
>
> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev <
> osgi-dev@mail.osgi.org> wrote:
>
> Hi,
>
> I have in my repository a bundle A-2.0.1 that exports packages with
> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
> version 2.0.3. Version A-2.0.3 fixes a bug.
>
> I have a bundle B that imports the packages from A with import
> statements "... version=[2.0.3,3)" because the bug fix is crucial for
> the proper working of B.
>
> Clicking on "Resolve" in bndtools, I get a resolution with bundle
> A-2.0.1. I understand that this complies with the specification ("It is
> recommended to ignore the micro part of the version because systems tend
> to become very rigid if they require the latest bug fix to be deployed
> all the time.").
>
> What I don't understand is the rationale. I don't see any drawbacks in
> deploying the latest bug fix. Of course, there's always the risk of
> introducing a new bug with a new version, even if it is supposed to only
> fix a bug in the previous version. But if you're afraid of this, you may
> also not allow imports with version ranges such as "[1.0,2)" (for
> consumers).
>
> In my case, I now have to distribute bundle B with a release note to
> configure the resolution in such a way that only A 2.0.3 and up is used.
> Something that you would expect to happen automatically looking at the
> import statement. And if I want to make sure that the release note is
> not overlooked, the only way seems to be to check the version of "A" at
> run-time in the activation of "B". This is downright ugly.
>
>  - Michael
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
>
>
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Tim Ward via osgi-dev]

>> Considering this, lowering a lower bound of an Import-Package statement when 
>> resolving should be acknowledged as a bug. 
>> 

Bnd does not alter the version used when resolving, as this would give 
“incorrect” answers that don’t resolve. The resolver must use the exact 
metadata from the bundle manifest, as that it what the framework uses at 
runtime. 

What Peter said is that bnd ignores the micro version at *build* time when 
*generating* your manifest. This is why one of the first things that I asked 
was “are you sure that your package import is for the micro version you want”. 
It is possible to make bnd apply micro versions in its generated imports, but 
it isn’t the default. My guess is that your bundle doesn’t really require what 
you think it requires.

If your bundle is built with a range that doesn’t include micro version numbers 
in its imports then there is no restriction for the resolver to use in 
deciding. At that point the bnd resolver heuristics will kick in to *try* to 
give you the highest version that satisfies your dependencies, but it may not 
be possible in all cases (this goes back to my well-curated repository 
argument). If you are able to share the workspace, or even just the repository 
index + your initial requirements, then we could probably attempt tell you why 
it’s picking what it’s picking. It’s non-trivial to reverse engineer though.

All the best,

Tim

> On 18 Jun 2019, at 09:54, Michael Lipp via osgi-dev  
> wrote:
> 
> 
>>> Considering this, lowering a lower bound of an Import-Package statement 
>>> when resolving should be acknowledged as a bug. 
>>> 
>> I beg to differ ...
>> 
>> As said, you can set the consumer/provider policy to your desired strategy.
>> 
> So having default settings in the tool that cause a behavior that does not 
> comply with the specification should not be considered a bug?
> 
>  - Michael
> 
> 
> 
>> 
>> Kind regards,
>> 
>>  Peter Kriens
>> 
>>> On 18 Jun 2019, at 10:33, Michael Lipp mailto:m...@mnl.de>> 
>>> wrote:
>>> 
>>> 
 
 I expect there are two things at play. First, OSGi specifies things as you 
 indicate. An import of [1.2.3.qualifier,2) must not select anything lower 
 than 1.2.3.qualifier. Second, bnd does have heuristics that do drop the 
 qualifier and micro part in calculating the import ranges from the exports 
 on the class path.
>>> Thanks for the clarification, I think this explains things.
>>> 
 [...]
 
 Conclusion, the spec is perfect but the implementations apply heuristics 
 and may have bugs.
>>> The specification says (or defines, if you like): "micro - A change that 
>>> does not affect the API, for example, a typo in a comment or a bug fix in 
>>> an implementation." It explicitly invites the developer to indicate a bug 
>>> fix by incrementing the micro part. There's no hint or requirement that he 
>>> should increment the minor part to reflect a bug fix. I do not find your 
>>> statement "The definition of the micro version is that it should not make a 
>>> difference in runtime" to be supported by the spec or the Semantic 
>>> Versioning Whitepaper. Actually, this interpretation would restrict the 
>>> usage of the micro part to documentation changes because every bug fix 
>>> changes the runtime behavior. This is, after all, what it is intended to do.
>>> 
>>> Considering this, lowering a lower bound of an Import-Package statement 
>>> when resolving should be acknowledged as a bug. 
>>> 
>>>  - Michael
>>> 
>>> 
>>> 
 
 Kind regards,
 
Peter Kriens
 
> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev 
> mailto:osgi-dev@mail.osgi.org>> wrote:
> 
> Hi,
> 
> I have in my repository a bundle A-2.0.1 that exports packages with
> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
> version 2.0.3. Version A-2.0.3 fixes a bug.
> 
> I have a bundle B that imports the packages from A with import
> statements "... version=[2.0.3,3)" because the bug fix is crucial for
> the proper working of B.
> 
> Clicking on "Resolve" in bndtools, I get a resolution with bundle
> A-2.0.1. I understand that this complies with the specification ("It is
> recommended to ignore the micro part of the version because systems tend
> to become very rigid if they require the latest bug fix to be deployed
> all the time.").
> 
> What I don't understand is the rationale. I don't see any drawbacks in
> deploying the latest bug fix. Of course, there's always the risk of
> introducing a new bug with a new version, even if it is supposed to only
> fix a bug in the previous version. But if you're afraid of this, you may
> also not allow imports with version ranges such as "[1.0,2)" (for
> consumers).
> 
> In my case, I now have to distribute bundle B with a release note to
> configure the resolution in such a way that only A 2.0.3 and up is used.

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Michael Lipp via osgi-dev]

>> Considering this, lowering a lower bound of an Import-Package
>> statement when resolving should be acknowledged as a bug. 
>>
> I beg to differ ...
>
> As said, you can set the consumer/provider policy to your desired
> strategy.
>
So having default settings in the tool that cause a behavior that does
not comply with the specification should not be considered a bug?

 - Michael


>
> Kind regards,
>
> Peter Kriens
>
>> On 18 Jun 2019, at 10:33, Michael Lipp > > wrote:
>>
>>
>>>
>>> I expect there are two things at play. First, OSGi specifies things
>>> as you indicate. An import of [1.2.3.qualifier,2) must not select
>>> anything lower than 1.2.3.qualifier. Second, bnd does have
>>> heuristics that do drop the qualifier and micro part in calculating
>>> the import ranges from the exports on the class path.
>>
>> Thanks for the clarification, I think this explains things.
>>
>>> [...]
>>>
>>> Conclusion, the spec is perfect but the implementations apply
>>> heuristics and may have bugs.
>>
>> The specification says (or defines, if you like): "|micro| - A change
>> that does not affect the API, for example, a typo in a comment or a
>> bug fix in an implementation." It explicitly invites the developer to
>> indicate a bug fix by incrementing the micro part. There's no hint or
>> requirement that he should increment the minor part to reflect a bug
>> fix. I do not find your statement "The definition of the micro
>> version is that it should not make a difference in runtime" to be
>> supported by the spec or the Semantic Versioning Whitepaper.
>> Actually, this interpretation would restrict the usage of the micro
>> part to documentation changes because every bug fix changes the
>> runtime behavior. This is, after all, what it is intended to do.
>>
>> Considering this, lowering a lower bound of an Import-Package
>> statement when resolving should be acknowledged as a bug.
>>
>>  - Michael
>>
>>
>>>
>>> Kind regards,
>>>
>>> Peter Kriens
>>>
 On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev
 mailto:osgi-dev@mail.osgi.org>> wrote:

 Hi,

 I have in my repository a bundle A-2.0.1 that exports packages with
 version 2.0.1 and a bundle A-2.0.3 that exports these packages with
 version 2.0.3. Version A-2.0.3 fixes a bug.

 I have a bundle B that imports the packages from A with import
 statements "... version=[2.0.3,3)" because the bug fix is crucial for
 the proper working of B.

 Clicking on "Resolve" in bndtools, I get a resolution with bundle
 A-2.0.1. I understand that this complies with the specification ("It is
 recommended to ignore the micro part of the version because systems
 tend
 to become very rigid if they require the latest bug fix to be deployed
 all the time.").

 What I don't understand is the rationale. I don't see any drawbacks in
 deploying the latest bug fix. Of course, there's always the risk of
 introducing a new bug with a new version, even if it is supposed to
 only
 fix a bug in the previous version. But if you're afraid of this,
 you may
 also not allow imports with version ranges such as "[1.0,2)" (for
 consumers).

 In my case, I now have to distribute bundle B with a release note to
 configure the resolution in such a way that only A 2.0.3 and up is
 used.
 Something that you would expect to happen automatically looking at the
 import statement. And if I want to make sure that the release note is
 not overlooked, the only way seems to be to check the version of "A" at
 run-time in the activation of "B". This is downright ugly.

  - Michael


 ___
 OSGi Developer Mail List
 osgi-dev@mail.osgi.org 
 https://mail.osgi.org/mailman/listinfo/osgi-dev
>>>
>>
>

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Peter Kriens via osgi-dev]

> Considering this, lowering a lower bound of an Import-Package statement when 
> resolving should be acknowledged as a bug. 
> 
I beg to differ ...

As said, you can set the consumer/provider policy to your desired strategy.


Kind regards,

Peter Kriens

> On 18 Jun 2019, at 10:33, Michael Lipp  wrote:
> 
> 
>> 
>> I expect there are two things at play. First, OSGi specifies things as you 
>> indicate. An import of [1.2.3.qualifier,2) must not select anything lower 
>> than 1.2.3.qualifier. Second, bnd does have heuristics that do drop the 
>> qualifier and micro part in calculating the import ranges from the exports 
>> on the class path.
> Thanks for the clarification, I think this explains things.
> 
>> [...]
>> 
>> Conclusion, the spec is perfect but the implementations apply heuristics and 
>> may have bugs.
> The specification says (or defines, if you like): "micro - A change that does 
> not affect the API, for example, a typo in a comment or a bug fix in an 
> implementation." It explicitly invites the developer to indicate a bug fix by 
> incrementing the micro part. There's no hint or requirement that he should 
> increment the minor part to reflect a bug fix. I do not find your statement 
> "The definition of the micro version is that it should not make a difference 
> in runtime" to be supported by the spec or the Semantic Versioning 
> Whitepaper. Actually, this interpretation would restrict the usage of the 
> micro part to documentation changes because every bug fix changes the runtime 
> behavior. This is, after all, what it is intended to do.
> 
> Considering this, lowering a lower bound of an Import-Package statement when 
> resolving should be acknowledged as a bug. 
> 
>  - Michael
> 
> 
> 
>> 
>> Kind regards,
>> 
>>  Peter Kriens
>> 
>>> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I have in my repository a bundle A-2.0.1 that exports packages with
>>> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
>>> version 2.0.3. Version A-2.0.3 fixes a bug.
>>> 
>>> I have a bundle B that imports the packages from A with import
>>> statements "... version=[2.0.3,3)" because the bug fix is crucial for
>>> the proper working of B.
>>> 
>>> Clicking on "Resolve" in bndtools, I get a resolution with bundle
>>> A-2.0.1. I understand that this complies with the specification ("It is
>>> recommended to ignore the micro part of the version because systems tend
>>> to become very rigid if they require the latest bug fix to be deployed
>>> all the time.").
>>> 
>>> What I don't understand is the rationale. I don't see any drawbacks in
>>> deploying the latest bug fix. Of course, there's always the risk of
>>> introducing a new bug with a new version, even if it is supposed to only
>>> fix a bug in the previous version. But if you're afraid of this, you may
>>> also not allow imports with version ranges such as "[1.0,2)" (for
>>> consumers).
>>> 
>>> In my case, I now have to distribute bundle B with a release note to
>>> configure the resolution in such a way that only A 2.0.3 and up is used.
>>> Something that you would expect to happen automatically looking at the
>>> import statement. And if I want to make sure that the release note is
>>> not overlooked, the only way seems to be to check the version of "A" at
>>> run-time in the activation of "B". This is downright ugly.
>>> 
>>>  - Michael
>>> 
>>> 
>>> ___
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org 
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> 
> 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Michael Lipp via osgi-dev]

>
> I expect there are two things at play. First, OSGi specifies things as
> you indicate. An import of [1.2.3.qualifier,2) must not select
> anything lower than 1.2.3.qualifier. Second, bnd does have heuristics
> that do drop the qualifier and micro part in calculating the import
> ranges from the exports on the class path.

Thanks for the clarification, I think this explains things.

> [...]
>
> Conclusion, the spec is perfect but the implementations apply
> heuristics and may have bugs.

The specification says (or defines, if you like): "|micro| - A change
that does not affect the API, for example, a typo in a comment or a bug
fix in an implementation." It explicitly invites the developer to
indicate a bug fix by incrementing the micro part. There's no hint or
requirement that he should increment the minor part to reflect a bug
fix. I do not find your statement "The definition of the micro version
is that it should not make a difference in runtime" to be supported by
the spec or the Semantic Versioning Whitepaper. Actually, this
interpretation would restrict the usage of the micro part to
documentation changes because every bug fix changes the runtime
behavior. This is, after all, what it is intended to do.

Considering this, lowering a lower bound of an Import-Package statement
when resolving should be acknowledged as a bug.

 - Michael


>
> Kind regards,
>
> Peter Kriens
>
>> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev
>> mailto:osgi-dev@mail.osgi.org>> wrote:
>>
>> Hi,
>>
>> I have in my repository a bundle A-2.0.1 that exports packages with
>> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
>> version 2.0.3. Version A-2.0.3 fixes a bug.
>>
>> I have a bundle B that imports the packages from A with import
>> statements "... version=[2.0.3,3)" because the bug fix is crucial for
>> the proper working of B.
>>
>> Clicking on "Resolve" in bndtools, I get a resolution with bundle
>> A-2.0.1. I understand that this complies with the specification ("It is
>> recommended to ignore the micro part of the version because systems tend
>> to become very rigid if they require the latest bug fix to be deployed
>> all the time.").
>>
>> What I don't understand is the rationale. I don't see any drawbacks in
>> deploying the latest bug fix. Of course, there's always the risk of
>> introducing a new bug with a new version, even if it is supposed to only
>> fix a bug in the previous version. But if you're afraid of this, you may
>> also not allow imports with version ranges such as "[1.0,2)" (for
>> consumers).
>>
>> In my case, I now have to distribute bundle B with a release note to
>> configure the resolution in such a way that only A 2.0.3 and up is used.
>> Something that you would expect to happen automatically looking at the
>> import statement. And if I want to make sure that the release note is
>> not overlooked, the only way seems to be to check the version of "A" at
>> run-time in the activation of "B". This is downright ugly.
>>
>>  - Michael
>>
>>
>> ___
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org 
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Micro version ignored when resolving, rationale?

[Peter Kriens via osgi-dev]

As Tim indicates we need more information. 

I expect there are two things at play. First, OSGi specifies things as you 
indicate. An import of [1.2.3.qualifier,2) must not select anything lower than 
1.2.3.qualifier. Second, bnd does have heuristics that do drop the qualifier 
and micro part in calculating the import ranges from the exports on the class 
path.

When bnd builds a bundle it calculates the import range based on the package it 
was compiled against. Bnd finds the version looking at packageinfo, 
package-info.class, and the manifest. 

It then checks if that package is 'provided' or 'consumed' by the bundle, and 
from this information it calculates the range. The base version does indeed 
drop the qualifier and the micro version. I hope dropping the qualifier sounds 
logical to you? If you do not drop the qualifier you always need a fresh bundle 
with whatever you do. This is hell.

Since the micro version in a semantic version cannot make a difference it is 
logically safe to drop that one as well. The definition of the micro version is 
that it should not make a difference in runtime. Having a bug fix in a micro 
version is just plain wrong. Why have a spec when a tool cannot rely on its 
semantics?

At the time when we're starting with this this heuristic made things a lot 
easier to work with. Although the micro version is less volatile than the 
qualifier, our experience was that you ended up in a similar hell that the most 
minute change required everything to change. Especially since we did not have a 
resolver at that time. We've got almost 18 years of experience with this model 
and I think it has worked quite well so far. However, with the resolver going 
mainstream in the last few years maybe we need to revisit it. 

If you do not agree with the heuristic you can set the policy for the provider 
and consumer import range yourself. See 
https://bnd.bndtools.org/instructions/provider_policy.html 
 Personally I would 
not do this because your then trying to fix the original error (a bug fix in a 
micro version) in the wrong place. Although this can be a quick fix, in my 
experience these hacks tend to exponentially increase the complexity of the 
build over time since you can no longer rely on the established rules, forcing 
you to make specials everywhere over time.

In your case you or someone in your team did not apply the rules for semantic 
versioning. That happens, especially when you have to rely on external 
software. In that case you can manually apply the import range in the 
manifest/bnd.bnd file. This exact import range must be obeyed by the resolver. 

That said, if 2.0.1 and 2.0.3 are available then it would be nice if the 
resolver would prefer the highest possible version as a heuristic. In bnd we 
compile against the lowest version to keep the base as low as possible but in 
runtime we prefer the highest allowed version. I assumed that the bnd resolver 
had this behavior since we order the resources. Maybe there were other 
constraints that made 2.0.3 less attractive than 2.0.1. To know that we need to 
know more about the exact setup.

Conclusion, the spec is perfect but the implementations apply heuristics and 
may have bugs.

Kind regards,

Peter Kriens

> On 17 Jun 2019, at 12:14, Michael Lipp via osgi-dev  
> wrote:
> 
> Hi,
> 
> I have in my repository a bundle A-2.0.1 that exports packages with
> version 2.0.1 and a bundle A-2.0.3 that exports these packages with
> version 2.0.3. Version A-2.0.3 fixes a bug.
> 
> I have a bundle B that imports the packages from A with import
> statements "... version=[2.0.3,3)" because the bug fix is crucial for
> the proper working of B.
> 
> Clicking on "Resolve" in bndtools, I get a resolution with bundle
> A-2.0.1. I understand that this complies with the specification ("It is
> recommended to ignore the micro part of the version because systems tend
> to become very rigid if they require the latest bug fix to be deployed
> all the time.").
> 
> What I don't understand is the rationale. I don't see any drawbacks in
> deploying the latest bug fix. Of course, there's always the risk of
> introducing a new bug with a new version, even if it is supposed to only
> fix a bug in the previous version. But if you're afraid of this, you may
> also not allow imports with version ranges such as "[1.0,2)" (for
> consumers).
> 
> In my case, I now have to distribute bundle B with a release note to
> configure the resolution in such a way that only A 2.0.3 and up is used.
> Something that you would expect to happen automatically looking at the
> import statement. And if I want to make sure that the release note is
> not overlooked, the only way seems to be to check the version of "A" at
> run-time in the activation of "B". This is downright ugly.
> 
>  - Michael
> 
> 
> ___
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
>