Are you referring to http://www.osgi.org/blog/2010/01/backward-compatibility.html ?
On Thu, May 6, 2010 at 08:46, David Bosschaert <[email protected]>wrote: > 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 > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
