On 2009-01-21 23:07, BJ Hargrave wrote:
I don't think any change to bnd is needed.
For a package which contains interfaces meant to be implemented by the
importer, then it is a breaking change to add new methods to the
interfaces. This is a 1.0 to 2.0 version change. Not a 1.0 to 1.1 change
This is why it is probably a best practice for a package to either
contain interfaces to be used by an importer or to be implemented by an
importer. A package should never contain both types of interfaces since
it makes versioning the package more awkward.
Sorry if I misunderstand your statement, but I think that _all_ interfaces are
of both types. Each and every interface is supposed to be implemented by an
importer and used by another importer.
--
*BJ Hargrave*
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_
[email protected]_ <mailto:[email protected]>
office: +1 386 848 1781
mobile: +1 386 848 3788
From: Peter Kriens <[email protected]>
To: OSGi Developer Mail List <[email protected]>
Date: 2009/01/21 12:48
Subject: Re: [osgi-dev] osgi and version numbers
Sent by: [email protected]
------------------------------------------------------------------------
bnd already supports a central version policy. However, this does not
distinguish between clients of an interface and implementers of an
interface. It seems if you implement an interface in an imported
package you want: [1.2,1.3) but if you only use interfaces or classes
from that package you want: [1.2,2.0). I think this might be very
useful but I have to try it out ... when I have time again.
Kind regards,
Peter Kriens
On 20 jan 2009, at 15:09, Mirko Jahn wrote:
> Hi Jeff,
>
> I have no real insight in what the OSGi is planning on doing, but at
> least from my perspective, it should be clear (although only a few
> people stick to it). The versions in the spec and in general any
> package that is exposed are versioned independently from the product
> and/or bundle. This holds true for the spec so far. Currently we have
> R 4.1 and to illustrate it package org.osgi.framework has version 1.4
> and org.osgi.service.packageadmin has 1.2 for instance - not related
> at all to the spec version.
>
> As you indicated, only binary compatible changes result in a minor
> version change. Having no changes at all in the public API should
> increase the micro version, but this in return should not happen in a
> spec (although I think I might come up with a use case), anyway of
> course changes which are not compatible at all have to result in a
> major version increase. When applying the version range, remember that
> as soon as you implement a specific interface like BundleListener, you
> can't use the major version as range delimiter, but the minor version.
> Binary compatibility is not given for implementations for instance.
> (org.osgi.framework;version="[1.4.0,1.5.0)" instead of
> org.osgi.framework;version="[1.4.0,2.0.0)" when implementing a
> BundleListener in your bundle.) Fortunately the spec doesn't describe
> dependencies on bundle level, because here more series problems are
> surfacing when investigating compatibility issues (like what version
> change implies a changed reexport?). Of course there is much more to
> say and consider, but I guess that's deviating from the actual topic.
>
> To wrap it up, I think it is fair to assume the next version(s) will
> stick to the rules applied before. Maybe one of the officials or
> someone more familiar with the process can comment on this one too.
>
> My 2 cents,
> Mirko
>
> On Tue, Jan 20, 2009 at 5:22 AM, Jeff McAffer <[email protected]> wrote:
>> Do you think that OSGi will evolve its package version numbers in a
>> way
>> similar to the Eclipse version numbering schemes? That is, does it
>> make any
>> sense today to spec Import-Package elements along the lines of
>> org.osgi.service.component;version="[1.0.0,2.0.0)",
>> org.osgi.service.http;version="[1.2.0,2.0.0)"
>> with an expectation that versions of these services fitting these
>> ranges
>> will be binary backward compatible?
>>
>> What is the best practice recommendation for people writing bundles
>> now but
>> anticipating changes in OSGi 2.0/5.0/whatever the next real big
>> spec change
>> is...
>>
>> Jeff
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected]
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
------------------------------------------------------------------------
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
______________________________________________________________
Nektarios K. Papadopoulos
Senior Engineer
Home Automation Group
inAccess Networks
______________________________________________________________
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
