Hi David, It's a good point. Recently a white paper has been worked on in the OSGi Alliance about this subject too. I couldn't find a public link to it yet, but will send it on as soon as I have it... One conclusion of the white paper is that you can't fully automate this as the version change depends on the role of the interface that has been changed.
Here's a really short summary of some of the content... * Let's say you have an interface X version 1.2 that you modify to include a new method. This would break backwards compatibility for people who implement this interface. Whether this will bump the version to 1.3 or 2.0 depends on who typically implements this interface: + If the interface is normally implemented by framework implementors (including compendium spec implementors), the version should bump to 1.3. This is because the new interface is still compatible with users of it. + If the interface is normally implemented by user bundles, the version should bump to 2.0 as the change is likely to change user builds. While there could be a tool that identifies the changed interfaces, deciding the new version number still seems to require human brainpower. Beyond that there are semantic changes that could have been introduced without changing the API, which a tool would never be able to find... So I guess you're in a difficult situation in that deciding the new version shouldn't really be an afterthought done at the very end. The decision should be made during development by the developer who knows about the changes he or she is making... Best regards, David On 6 May 2010 01:22, David Jencks <[email protected]> wrote: > I've been trying to figure out some package versions for some geronimo code > today and think that, given an existing bundle and its next version, it's > pretty much beyond human capabilities to correctly determine the package > versions for the new bundle. Certainly I don't think anyone trying to tie up > the loose ends for a release is going to be able to do it correctly. > > Are there any tools available to help with this? > > I don't think that anyone can expect any correct package versions in bundles > until this is well supported by tooling. > > Ideally I'd like the maven-bundle-plugin to have a goal to determine the > package versions by analyzing the code differences between the current code > and the previous released version of a bundle, and for the normal operation > of the plugin to compare these correct versions with explicitly configured > versions to make it obvious when you have unintentionally changed > compatibility. > > thanks > david jencks > >
