Hi Jeff, I have no real insight in what the OSGi is planning on doing, but at least from my perspective, it should be clear (although only a few people stick to it). The versions in the spec and in general any package that is exposed are versioned independently from the product and/or bundle. This holds true for the spec so far. Currently we have R 4.1 and to illustrate it package org.osgi.framework has version 1.4 and org.osgi.service.packageadmin has 1.2 for instance - not related at all to the spec version.
As you indicated, only binary compatible changes result in a minor version change. Having no changes at all in the public API should increase the micro version, but this in return should not happen in a spec (although I think I might come up with a use case), anyway of course changes which are not compatible at all have to result in a major version increase. When applying the version range, remember that as soon as you implement a specific interface like BundleListener, you can't use the major version as range delimiter, but the minor version. Binary compatibility is not given for implementations for instance. (org.osgi.framework;version="[1.4.0,1.5.0)" instead of org.osgi.framework;version="[1.4.0,2.0.0)" when implementing a BundleListener in your bundle.) Fortunately the spec doesn't describe dependencies on bundle level, because here more series problems are surfacing when investigating compatibility issues (like what version change implies a changed reexport?). Of course there is much more to say and consider, but I guess that's deviating from the actual topic. To wrap it up, I think it is fair to assume the next version(s) will stick to the rules applied before. Maybe one of the officials or someone more familiar with the process can comment on this one too. My 2 cents, Mirko On Tue, Jan 20, 2009 at 5:22 AM, Jeff McAffer <[email protected]> wrote: > Do you think that OSGi will evolve its package version numbers in a way > similar to the Eclipse version numbering schemes? That is, does it make any > sense today to spec Import-Package elements along the lines of > org.osgi.service.component;version="[1.0.0,2.0.0)", > org.osgi.service.http;version="[1.2.0,2.0.0)" > with an expectation that versions of these services fitting these ranges > will be binary backward compatible? > > What is the best practice recommendation for people writing bundles now but > anticipating changes in OSGi 2.0/5.0/whatever the next real big spec change > is... > > Jeff > _______________________________________________ > 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
