> 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 <[email protected]> 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 <[email protected]
>>> <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
