Hi, Figured I'd weight in, as I have a fairly emotional investment in the subject and I'm not happy with the state of modularity [Java or otherwise] (nor Eclipse, but I'll hold my frustrations on that topic for another discussion group) (and, don't even get me started on Maven... that or Bill Cower); First, I want clear separation of API from implementation, including deploy time (meaning, separate bundles for APIs versus Implementations); Second, I want versioning at the service level... Now, if you are careful, you can sort of attain versioning at the service level a la versioning at the package level and bundle level... of course, attempting to educate the public on "the main sequence band" is a lost cause, so... You map versions of implementations to APIs and APIs to clients (conceptually, at the service level); What I recommend is that you bump the major number when you "break" the API; So, implementations follow the major and minor numbering scheme of the API, and just bump the micro number for patches and bug fixes (to include performance upgrades as well); As for the whole "textual suffix, e.g., '.SNAPSHOT' ".. well, the verdict is still out [for me]... FWIW (for what it's worth, however many grains of salt), Craig
________________________________ From: [email protected] on behalf of Mirko Jahn Sent: Tue 1/20/2009 9:09 AM To: OSGi Developer Mail List Subject: Re: [osgi-dev] osgi and version numbers 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
<<winmail.dat>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
