I routinely separate API from IPML period;
An API is strictly package based;
An IMPL is strictly service based;
When the API is broken ('er not backwards compatible), I bump the major number;
Thusly, the IMPL version numbering follows suit;
I've never had a problem with bnd or unit testing or run time wiring following
this simple practice; I can get away with simple junit/jmock/hamcrest-matchers
for just about anything/everything;
And I don't even need any maven at all, period, for anything; I have never been
in any situation where I've ever felt I would need a maven;
Reminder: once a bundle is built, it NEVER has to be rebuilt, EVER; Once built,
it's dependencies are STRICTLY run time; Simply put, if you do not have a
guarantee for api breakage (you don't have a design-by-contract API), then you
wire to a specific version only; By standard practice, my contract API is
simply "bump the major number if you break the API";
Now if only OSGi supported versioning of services... but you can simply put the
major number in your service name;
As for repositories... deep breath... maven has F'd this simple concept up
too... All you need is to browse the APIs and their contract specification;
Then you pull down the API bundle and the impl bundle(s) depending on what
features they provide;
And, if an API changes, you MUST bring a human in the loop; You do NOT
routinely just bring some latest component down and rerun some test and think
you're done; That is SO WRONG on every level;
TGIF
From: David Jencks
Sent: Thu 5/6/2010 5:20 PM
To: dev@felix.apache.org
Subject: Re: Tools to determine correct package version?
On May 6, 2010, at 11:25 AM, David Bosschaert wrote:
>>> 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)
>
> True, but the missing piece of information here is that using bundles
> sometimes also implement an interface (the Whiteboard Pattern). Take
> for example the Configuration Admin Service org.osgi.service.cm
> package version 1.3. In there you find a ConfigurationAdmin interface
> which is implemented by framework/spec implementors, while its
> ManagedService is implemented by users. Hence adding a method to the
> ConfigurationAdmin interface will only change the version of the
> package to 1.4. But adding a method to ManagedService will change it
> to 2.0
I can see a couple possible ways around this:
1. Claim that this package was not designed properly and should be 2 packages,
one containing ConfigurationAdmin and one containing ManagedService which can
then be versioned independently
2. Refine ones understanding of package versions for implementors so that major
version bump means "we took some methods/interfaces out" and minor version
means "we added some new methods" which seems to be what Peter's version
policies imply.
(2) seems more reasonable to me, but I'm at the point where I need a bunch of
simple concrete examples I can look at to believe anything in this area.
thanks
david jencks
>
> Best regards,
>
> David
