>> 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 https://mail.osgi.org/mailman/listinfo/osgi-dev
