Ferry, thanks for the pointer. I was aware of the concept of semantic versioning, not in the specific context of OSGi though. I read the paper on the OSGi wiki. And I still maintain what I wrote above.
Example: My Maven dependency is camel-core 2.13.2. Based on the imports of the code this is converted into one or more package imports from that bundle, e.g. 'org.apache.camel;version="[2.13,3)", org.apache.camel.impl;version="[2.13,3)"', etc. I might have chosen the specific version 2.13.2 because it fixed a bug in v. 2.13.1 that affects me . Or I might have downgraded from 2.14.0 because it introduced a bug. Now, across all environments (development, test, integration, production, you name it) I have to ensure that my code always runs with that exact version of the camel-core bundle. Which is not guaranteed by the version range [2.13,3) that has been generated for me. As for my own code. I have a multi-module maven project. All or some modules will be OSGi bundles. They all have the same release cycle. Which is why I combined them in a multi-module project. So all modules are integration-tested against each other. At the same version. Even though version 3.0.0 of module A has a very high probability to work with version 3.0.1 of module B, it has never been tested that way. And therefor should never be deployed in that combination. Again, if my imports are generated as [3.0,4), then there is no guarantee that this cannot happen by accident. Might be my problem is that I don't see how to distinguish between the API and its provider. The bundle "camel-core" is both, is it not? The same is true for almost all 3rd party libraries I normally work with. Very few separate the API from the provider in separate bundles. Of course with my own code I could go the extra mile maintain separate modules for the API and its provider. Thanks for your help! Ralf -- View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123p5010137.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
