> > 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 <osgi-dev@mail.osgi.org> > Sent by: osgi-dev-boun...@mail.osgi.org > To: Neil Bartlett <njbartl...@gmail.com>, OSGi Developer Mail List > <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 >> <osgi-dev@mail.osgi.org <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 <m...@mnl.de >>>> <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 >>>>>> <osgi-dev@mail.osgi.org <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 <mailto:osgi-dev@mail.osgi.org> >>>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> >>>> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto: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
