Re: [osgi-dev] Micro version ignored when resolving, rationale?
"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?
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?
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?
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?
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
