felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Phillips <lcphill...@praxiseng.com>
Subject RE: Tools to determine correct package version?
Date Fri, 07 May 2010 11:20:17 GMT
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;


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.

david jencks
> Best regards,
> David

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message