Most companies follows a rather simple versioning rule while releasing their product. They increase major version number if they do not want to support backward compatibility, though it may be backward compatible. Having said so while importing package its a good idea to keep version range like [x.y.z,(x+1).0.0). This way you are making a good assumption about your code being able to work with backward compatible releases of third party library.
-Rajesh > Hello, > > Are there guidelines that would be useful in defining version > constraints when OSGi-enabling 3rd party libraries? Typically, should > constraints be made as broad as possible to enable flexible resolution, or > should they be made as narrow as possible to enable multiple versions to > coexist? The OSGi specification says "the import should be as > unconstrained > as possible to allow the resolver maximum flexibility" in the context of > importing exported packages. But doesn't too unconstrained also mean that > multiple variants cannot execute side-by-side? > > To add some context to the question, we are looking at OSGi-enabling > Tuscany > which uses around 150 3rd party libraries. Many of these libraries are > likely to be shared with applications, and in some cases, applications may > want to use a different version of a library and share it with Tuscany, > and > in some other cases applications may want to use a different version of a > 3rd party library from Tuscany without any sharing. Is there a recommended > versioning technique which would do the right thing in a vast majority of > cases? Is there any way that we can completely avoid applications ever > having to uninstall Tuscany's version of 3rd party bundles, regardless of > what sharing/isolation they require? > > > Thank you... > > Regards, > > Rajini > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
