On May 5, 2010, at 11:46 PM, David Bosschaert 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.
Maybe I misunderstand this, but I thought that recent bnd's (not yet in
maven-bundle-plugin despite my best efforts) were based on the idea that you'd
bump the version to 1.3, and
- using bundles would import with a version range of [1.2,2)
- implementing bundles would import with a version range of [1.2,1.3)
These go with the (mavenized) instructions
<_versionpolicy-impl>[$(version;==;$(@)),$(version;=+;$(@)))</_versionpolicy-impl>
<_versionpolicy-uses>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy-uses>
Is there some reason this wouldn't work generally, thus making the next version
unambiguous from a syntactic viewpoint?
>
> 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...
>
I'd be pretty happy if the hypothetical tool would just deal with syntax.
Syntactic analysis should give you a minimum next version, so the tool could
fail the build if you are trying to use a version less than this minimum. If
you know of semantic considerations as well you can supply a larger version by
hand.
> 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...
For semantic concerns, yes.... but having some syntactic checking and
suggestions would be pretty useful.
thanks
david jencks
>
> 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
>>
>>
