that is exactly what I am asking. When OSGi breaks the binary
compatibility, will the major version number be incremented. The
answer appears to be yes. Great.
Thanks
Jeff
BJ Hargrave wrote:
I am not sure what you
are asking for.
Section 3.6.2 of the spec outlines the common versioning policy of
major
changes being incompatible which is how we do operate at OSGi with
respect
to versioning. Hence the framework package is still 1.x.
I can see changing all the
package.html
files to use ranges in the example import package statements.
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi
Alliance
[email protected]
|
office: +1 386 848 1781
mobile: +1 386 848 3788
|
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
