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

[Tim Ward via osgi-dev]

Right, so lets look at these one by one:

>  "The importer's version range matches the exporter's version. See Semantic 
> Versioning 
> .”
>  The reference to semantic versioning makes the content of that section part 
> of the specification of the resolving process. But as you and others have 
> pointed out, build/packaging and resolving are "very separate steps". How to 
> apply exactly the information from section "Semantic Versioning" to the 
> resolving process (i.e. to matching the importer's and exporter's versions) 
> is left open to interpretation. Reading the specification, I was unsure if 
> the recommendation to ignore the micro part should be applied to the 
> resolving process. This caused a lot of confusion on my side. Unless 
> everybody agrees that reading the specification in this way is my fault only 
> and the intended meaning is obvious to everybody else -- even without a 
> decade of OSGi experience -- I think there is room for improvement.
> 
So I think your confusion here comes from the difference between “normative” 
statements, which lay out the strict rules that must be followed, and 
“recommendations” (usually following the word “should”). A normative definition 
of version range syntax and meaning is available in Version Ranges 
.
 This strictly defines what version ranges are, including what matches and what 
doesn’t. You will note that micro versions are *never* ignored. If your version 
range puts a micro version into its floor or ceiling then that defines the 
matching space.

The Semantic Versioning section starts with the following statement: 

"Though the OSGi frameworks do not enforce a specific encoding for a 
compatibility policy, it is strongly recommended to use the following 
semantics."

This is the first big hint to say “this is a non-normative part of the spec, 
it’s useful information but doesn’t restrict what you do”. The end of the 
section goes on to recommend:

"Both consumers and providers should use the version they are compiled against 
as their base version. 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. For example, when compiled against version 
4.2.1.V201007221030, the base version should be 4.2.

A consumer of an API should therefore import a range that starts with the base 
version and ends with the next major change, for example:[4.2,5). A provider of 
an API should import a range that starts with the base version up to the next 
minor change, for example:[4.2,4.3)."

This exactly the default that bnd provides when packaging your bundle. It tries 
to find the lowest version bundle to compile against, then sets the version 
range in your Import Package statement appropriately. This default behaviour 
what you need to override to get a minimum import version including a micro 
version.

> Applying the information from the section "Semantic Versioning" to the 
> build/packaging process, I stumble about the recommendation "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." Sorry for being 
> obstinate, but when you read this and have my use case in mind (trying to 
> make sure that the resolver rules out everything below a specific bug fix 
> version) this recommendation simply does not make sense. And there is no 
> mentioning that specifying a lower bound with a micro part greater zero might 
> make sense (as everybody seems to be able to agree upon -- unless we are 
> talking about the special case of a bundle that only contains interfaces and 
> DTOs). Specifying a lower bound with a micro part effectively adds to the 
> information about two bundle's (their packages' to be precise) API 
> compatibility a "hint" for the resolver to only consider a subset of (API 
> compatible) providing bundles. This limits the flexibility (the resolver is 
> no longer allowed to compute a result with the buggy version(s) of the 
> referenced packages) but this is a limitation I intend. Of course, the spec 
> only "recommends" ignoring the micro part. But if a specification provides a 
> recommendation, it should also mention the scope to which it applies. And it 
> doesn't apply to my use case, which I -- obviously -- wouldn't consider 
> "exotic".
> 

The key part of this is that "Of course, the spec only "recommends" ignoring 
the micro part”. You are free to ignore recommendations when they don’t fit 
what you need. The expectation that a micro version greater than zero is a 
valid thing to do is implicit because
The version range syntax explicitly includes it and describes how to do it
The Semantic Versioning section recommends, rather than requires setting 

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

[Michael Lipp via osgi-dev]

Thanks for engaging yourself with my question.

I think my problems boil down to two issues that could (and maybe
should) be improved in the specification.

> 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.

And the steps have different rules. My problem is that the specification
lumps them together. I've cited this before: "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].
The reference to semantic versioning makes the content of that section
part of the specification of the resolving process. But as you and
others have pointed out, build/packaging and resolving are "very
separate steps". How to apply exactly the information from section
"Semantic Versioning" to the resolving process (i.e. to matching the
importer's and exporter's versions) is left open to interpretation.
Reading the specification, I was unsure if the recommendation to ignore
the micro part should be applied to the resolving process. This caused a
lot of confusion on my side. Unless everybody agrees that reading the
specification in this way is my fault only and the intended meaning is
obvious to everybody else -- even without a decade of OSGi experience --
I think there is room for improvement.

>> 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.

Applying the information from the section "Semantic Versioning" to the
build/packaging process, I stumble about the recommendation "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." Sorry
for being obstinate, but when you read this and have my use case in mind
(trying to make sure that the resolver rules out everything below a
specific bug fix version) this recommendation simply does not make
sense. And there is no mentioning that specifying a lower bound with a
micro part greater zero might make sense (as everybody seems to be able
to agree upon -- unless we are talking about the special case of a
bundle that only contains interfaces and DTOs). Specifying a lower bound
with a micro part effectively adds to the information about two bundle's
(their packages' to be precise) API compatibility a "hint" for the
resolver to only consider a subset of (API compatible) providing
bundles. This limits the flexibility (the resolver is no longer allowed
to compute a result with the buggy version(s) of the referenced
packages) but this is a limitation I intend. Of course, the spec only
"recommends" ignoring the micro part. But if a specification provides a
recommendation, it should also mention the scope to which it applies.
And it doesn't apply to my use case, which I -- obviously -- wouldn't
consider "exotic".

If the OSGi module layer wanted to keep the API compatibility expressed
by the Import-/Export-Package versions clean of hints for the resolver
then it should provide another means to propagate this requirement.
(Nobody brought this up, so it is probably a dead end: I did ponder if
an additional "Require-Bundle" header with bundle-version [2.0.3,3)
would be a better means to propagate the version requirement to the
resolver [instead of Import-Package with micro part greater 0]. But as
the usage of Require-Bundle is discouraged, I ruled this out. It would,
however, be a method to separate the API compatibility specification
from the resolver hint -- a remedy with side-effects, of course).

(As a side note: I do know about the difference between package versions
and bundle versions and the possible benefits of versioning packages
individually. However, bundle "A" is a library that also has its usages
outside the OSGi "ecosystem". And therefore -- as described e.g. in
"Wrapping libraries"
[https://bnd.bndtools.org/chapters/390-wrapping.html] and as it is
common practice when building such libraries with an 

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

[Tim Ward via osgi-dev]

gi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module.resolvingprocess
>  
> <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 <mailto:hargr...@us.ibm.com>
>>  
>>  
>> - Original message -
>> From: Michael Lipp via osgi-dev  
>> <mailto:osgi-dev@mail.osgi.org>
>> Sent by: osgi-dev-boun...@mail.osgi.org 
>> <mailto:osgi-dev-boun...@mail.osgi.org>
>> To: Neil Bartlett  <mailto:njbartl...@gmail.com>, OSGi 
>> Developer Mail List  <mailto:osgi-dev@mail.osgi.org>
>> 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 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

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-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 >>> <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.
>>>>
>>>>> [...]
>>>>>  
>>>>> Concl

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 <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 <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 <osgi-dev@mail.osgi.org> 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
 
 __

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
> 

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

[Neil Bartlett via osgi-dev]

"the specification, which states that the micro part of the
version should be ignored when resolving bundles"

The OSGi specification absolutely does NOT state this. Mainly for the
reasons you have laid out yourself.

Regards,
Neil.



On Mon, 17 Jun 2019 at 23:14, Michael Lipp via osgi-dev <
osgi-dev@mail.osgi.org> wrote:

> Hi Tim,
>
> I may have expressed myself badly. Nothing goes wrong, everything works
> according to the specification, which states that the micro part of the
> version should be ignored when resolving bundles.
>
> My question is whether anybody can explain why the behavior was
> specified in such an "unreasonable" way. I tried to explain why I
> consider the behavior "unreasonable": if I author and deliver a bundle
> ("B" in my Mail) and I know that it only works with a specific
> "bug-fixed" version of another bundle ("A-2.0.3") then there is no way
> to enforce that this version is used by my customer.
>
> "Import-Package" with "version=[2.0.3,3)" does not help, because the
> micro part is specified to be ignored. So effectively, requiring
> "version=[2.0.3,3)" is just like requiring "version=[2.0,3)" which makes
> the buggy versions "A-2.0.0" to "A-2.0.2" candidates for the resolution.
>
> Of course, I can state in the release notes of bundle "B" that a user of
> the bundle must take care to not have a version below 2.0.3 in his
> repository. But honestly, if the user happens to already have e.g.
> version A-2.0.1 in his repository due to a requirement that existed
> before adding my bundle to his application, and he adds my bundle and
> everything seems to work fine, how probable is it that he reads the
> release notes when --maybe days later-- something goes wrong because of
> the bug in A-2.0.1?
>
> If OSGI didn't specify that the micro part should be dropped, then
> everything would be fine. Resolution would only be possible if at least
> version 2.0.3 of "A" was available. So, why do we have this
> "unreasonable" specification?
>
>  - Michael
>
>
> Am 17.06.19 um 15:17 schrieb Tim Ward:
> > Hi Michael,
> >
> > I’m afraid that there’s quite a lot of missing information before I
> could come to a conclusion about what’s going on. What are your input
> requirements? Have you checked that B actually has the version range that
> you think it does? Are there two versions of A being deployed? If it’s
> possible to share the workspace then we might be able to bottom out what’s
> happening.
> >
> > Also, if 2.0.1 of A is known to be broken then why do you have it in the
> repository that you are resolving against? The best defence against “bad”
> resolutions is to have a well curated repository. As with many things
> garbage in == garbage out.
> >
> > All the best,
> >
> > Tim
> >
> >> On 17 Jun 2019, at 11: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]

Hi

> I may have expressed myself badly. Nothing goes wrong, everything works
> according to the specification, which states that the micro part of the
> version should be ignored when resolving bundles.

….

> If OSGI didn't specify that the micro part should be dropped, then
> everything would be fine. Resolution would only be possible if at least
> version 2.0.3 of "A" was available. So, why do we have this
> "unreasonable" specification?

So while the semantic versioning recommendations do say that “the micro version 
is meaningless” when it comes to backward compatibility there isn’t anywhere 
that says a micro version should be ignored when resolving. In fact the OSGi 
framework *must not* ignore the micro version. If you say that you need 
"[1.2.3,1.2.4)” then you will get 1.2.3.

This is why I’m saying that your “unexpected” resolution is an indication that 
something is wrong, either in your inputs, or (less likely) in bnd somewhere.

Tim


> On 17 Jun 2019, at 23:14, Michael Lipp via osgi-dev  
> wrote:
> 
> Hi Tim,
> 
> I may have expressed myself badly. Nothing goes wrong, everything works
> according to the specification, which states that the micro part of the
> version should be ignored when resolving bundles.
> 
> My question is whether anybody can explain why the behavior was
> specified in such an "unreasonable" way. I tried to explain why I
> consider the behavior "unreasonable": if I author and deliver a bundle
> ("B" in my Mail) and I know that it only works with a specific
> "bug-fixed" version of another bundle ("A-2.0.3") then there is no way
> to enforce that this version is used by my customer.
> 
> "Import-Package" with "version=[2.0.3,3)" does not help, because the
> micro part is specified to be ignored. So effectively, requiring
> "version=[2.0.3,3)" is just like requiring "version=[2.0,3)" which makes
> the buggy versions "A-2.0.0" to "A-2.0.2" candidates for the resolution.
> 
> Of course, I can state in the release notes of bundle "B" that a user of
> the bundle must take care to not have a version below 2.0.3 in his
> repository. But honestly, if the user happens to already have e.g.
> version A-2.0.1 in his repository due to a requirement that existed
> before adding my bundle to his application, and he adds my bundle and
> everything seems to work fine, how probable is it that he reads the
> release notes when --maybe days later-- something goes wrong because of
> the bug in A-2.0.1?
> 
> If OSGI didn't specify that the micro part should be dropped, then
> everything would be fine. Resolution would only be possible if at least
> version 2.0.3 of "A" was available. So, why do we have this
> "unreasonable" specification?
> 
>  - Michael
> 
> 
> Am 17.06.19 um 15:17 schrieb Tim Ward:
>> Hi Michael,
>> 
>> I’m afraid that there’s quite a lot of missing information before I could 
>> come to a conclusion about what’s going on. What are your input 
>> requirements? Have you checked that B actually has the version range that 
>> you think it does? Are there two versions of A being deployed? If it’s 
>> possible to share the workspace then we might be able to bottom out what’s 
>> happening.
>> 
>> Also, if 2.0.1 of A is known to be broken then why do you have it in the 
>> repository that you are resolving against? The best defence against “bad” 
>> resolutions is to have a well curated repository. As with many things 
>> garbage in == garbage out.
>> 
>> All the best,
>> 
>> Tim
>> 
>>> On 17 Jun 2019, at 11: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 

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

[Michael Lipp via osgi-dev]

Hi Tim,

I may have expressed myself badly. Nothing goes wrong, everything works
according to the specification, which states that the micro part of the
version should be ignored when resolving bundles.

My question is whether anybody can explain why the behavior was
specified in such an "unreasonable" way. I tried to explain why I
consider the behavior "unreasonable": if I author and deliver a bundle
("B" in my Mail) and I know that it only works with a specific
"bug-fixed" version of another bundle ("A-2.0.3") then there is no way
to enforce that this version is used by my customer.

"Import-Package" with "version=[2.0.3,3)" does not help, because the
micro part is specified to be ignored. So effectively, requiring
"version=[2.0.3,3)" is just like requiring "version=[2.0,3)" which makes
the buggy versions "A-2.0.0" to "A-2.0.2" candidates for the resolution.

Of course, I can state in the release notes of bundle "B" that a user of
the bundle must take care to not have a version below 2.0.3 in his
repository. But honestly, if the user happens to already have e.g.
version A-2.0.1 in his repository due to a requirement that existed
before adding my bundle to his application, and he adds my bundle and
everything seems to work fine, how probable is it that he reads the
release notes when --maybe days later-- something goes wrong because of
the bug in A-2.0.1?

If OSGI didn't specify that the micro part should be dropped, then
everything would be fine. Resolution would only be possible if at least
version 2.0.3 of "A" was available. So, why do we have this
"unreasonable" specification?

 - Michael


Am 17.06.19 um 15:17 schrieb Tim Ward:
> Hi Michael,
>
> I’m afraid that there’s quite a lot of missing information before I could 
> come to a conclusion about what’s going on. What are your input requirements? 
> Have you checked that B actually has the version range that you think it 
> does? Are there two versions of A being deployed? If it’s possible to share 
> the workspace then we might be able to bottom out what’s happening.
>
> Also, if 2.0.1 of A is known to be broken then why do you have it in the 
> repository that you are resolving against? The best defence against “bad” 
> resolutions is to have a well curated repository. As with many things garbage 
> in == garbage out.
>
> All the best,
>
> Tim
>
>> On 17 Jun 2019, at 11: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?

[Tim Ward via osgi-dev]

Hi Michael,

I’m afraid that there’s quite a lot of missing information before I could come 
to a conclusion about what’s going on. What are your input requirements? Have 
you checked that B actually has the version range that you think it does? Are 
there two versions of A being deployed? If it’s possible to share the workspace 
then we might be able to bottom out what’s happening.

Also, if 2.0.1 of A is known to be broken then why do you have it in the 
repository that you are resolving against? The best defence against “bad” 
resolutions is to have a well curated repository. As with many things garbage 
in == garbage out.

All the best,

Tim

> On 17 Jun 2019, at 11: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

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

[Michael Lipp via osgi-dev]

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