I think one of the key things we are missing is that there seems to be
sides to
versioning. This difference is very visible with interfaces.
If you add a method to an interface than the implementer can not live
with
the new version but the client is perfectly happy. I.e. it is quite
easy to
keep the client happy by being backward compatible but the implementer
of the
interface has much more stringent requirements. An implementer must
match the specification version 100%.
If you implement the log service, your Import-Package for the
org.osgi.service.log
MUST be a point release. You do not want to accidentally implement a
later release.
However, if you use the log service, point->infinite
is usually good enough. Or if you're anal, point to next incompatible
release.
Kind regards,
Peter Kriens
On 5 jun 2008, at 03:02, Jeff McAffer wrote:
The Eclipse versioning conventions can be found here
http://wiki.eclipse.org/index.php/Version_Numbering
As for tooling, PDE now (as of 3.4) includes some API tooling that
helps
with version numbering violations and breaking API changes (amongst
other
things). See
http://wiki.eclipse.org/Api_Tooling
What is missing:
- package version number management. We just ran out of time to do
this.
Expect it as one of the first things done in the next release cycle.
- compiling against lower bounds. To really be sure that you are
only using
things provided by the lower bound version of your prereqs you should
compile against it (or have kick ass tooling that validates your API
use).
This may actually be coming
- automatic generation of import version bounds. This is actually a
very
hard problem. Setting the lower bound automatically purely from an
API
signature basis it is tractable IF you have copies of all versions
of the
package API signatures available to you. Then you could do some
sort of
analysis and discover that the code calls only the API included in
version
1.2.3 or later (for example). Pragmatically however, there may be
other API
considerations that come into play (e.g., semantic changes, contract
clarifications, ...). Then there is the compilation problem (see
above).
On top of that there are context issues where it may not even make
sense for
you to import org.foo 1.2.3 with org.bar 3.2.1 even if technically
the API
signature constraints are met. Oh, and then there is testing.
I am a very strong believer in developer defined dependencies.
Tooling is
essential in making this easy (we are getting there with PDE and
bnd) but to
create well-engineered components one must pay close attention to your
dependencies. Reverse-engineering them from developed code can
provide a
great starting point and tools can help you stay in the bounds that
you
defined based on that starting point but ultimately a real live human
developer needs to be involved in crafting these dependencies.
The packages and versions you choose basically define the contract
you are
committing to. A lower lower bound means that you are constraining
yourself
to use only a certain level of function in a certain series of YOUR
bundles.
Raising your lower bound in a service release of your bundle for
example can
cause people's applications to stop running/resolving (they may not
be able
to supply the new version of the prereq).
A higher upper bound means you are willing to take on more risk in
your
bundle as a wider range of changes in your prerequisites is going to
be
tolerated. You have to trust the producer to be reasonable and
write your
code to be robust.
There is no silver bullet here IMHO. The tooling can be improved but
ultimately the burden belongs to a developer. In fact, in several
projects
I know of it is the architects and senior people who design these
dependencies. They don't just appear because some developer hit
Ctrl-space
and autocompleted to include whole new reams of function.
Jeff
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:osgi-dev-
[EMAIL PROTECTED] On Behalf Of Mirko Jahn
Sent: Wednesday, June 04, 2008 7:34 PM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Version constraints used in Import-Package
Well, unfortunately this is kinda true. I think the spec is great in
terms of capabilities, but first of all everyone needs to understand
the implications of version number schemes. OSGi is great to gain
quick benefits, but if it is adapted in a very simple way (only plain
exports without version numbers, imports without version ranges and
so
on) the benefits are very limited. Actually, I even think it might
cause sooner or later real problems with interoperability. More in
the
terms of awareness and training should be done. Otherwise we might
end
up with thousands of bundles not worth a thing, because we can't rely
on them. Everything has to be done by hand. The ultimate goal should
be to have tooling support to automatically generate these numbers.
The tool should detect version changes between releases on a semantic
and syntactic level and change the version numbers accordingly. No
human interaction should be required. This is the way to go I think.
The only thing the bundle developer should be involved with is
defining the version to export - even imports with version ranges
should be handled by the tool. This would leverage software reuse and
put modularization on a completely new level! Well, although this is
not impossible, it is far from reality right now and it is certainly
not part of a specification. It would be interesting if someone is
already working on something like this. I know Eclipse 3.4 is trying
to do things like that, but till now I couldn't find any
documentation
on that. If some knows anything, I would be interested to know about
it!
Cheers,
Mirko
On Wed, Jun 4, 2008 at 5:24 PM, Alan Cabrera <[EMAIL PROTECTED]>
wrote:
On Jun 4, 2008, at 1:21 AM, Rajini Sivaram wrote:
Thank you all for the replies with all the useful information and
pointers.
For versioning Tuscany bundles themselves, we are using
maven-bundle-plugin at the moment, which gives us import and "uses"
clauses
with version="2.0.0". Since this includes all versions from 2.0 to
infinity,
and we are not currently addressing execution of two different
versions of
Tuscany side-by-side, the default looks sufficient. We could change
it to
"[2.0.0,3.0.0)" to make it more specific, but either way, it should
be fine
for now.
I am still not entirely sure about versioning of 3rd party
libraries
distributed with Tuscany though. Since Tuscany is used to assemble
SOA
applications, Tuscany uses a large number of 3rd party libraries to
provide
different bindings and implementation types. Many of these 3rd
party
libraries may also be used by applications (either directly from
Tuscany or
from a different source). If for example, Tuscany's version of
wsdl4j used
import version "[1.6.2, 2.0,0)", and this version of Tuscany
doesn't
work
with wsdl4j version 1.7, doesn't the version range "[1.6.2, 2.0,0)"
prevent
an application from installing and using version 1.7 along with
Tuscany for
something else? So should the version range only specifically
include the
version range that Tuscany has been tested against? And then we run
into
problems with too narrow version ranges. And what happens when an
application is using wsdl4j from SpringSource or another repository
where a
different version range is included? How do we ensure that Tuscany
and
applications can all coexist?
Ahh, and here we find that OSGi has the same achilles heel as Maven.
I
anticipate that these kind of issues will be the basis for a shrill
of
complaints as they are in Maven.
I've had a fair bit of experience wiring in large sets of 3rd party
jars.
No one follows any single kind of version nomenclature and many
violate the
ones they espouse.
Setting a version range in anticipation of what down stream
application
assemblers will use will be a futile task. Only the Pope and my
mother-in-law are infallible and you're sure to get it wrong for
some
significant part of your community. The best you can do is set the
range
for what is safe for Tuscany in the hopes of providing accurate
information
for down stream application assemblers.
Regards,
Alan
_______________________________________________
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
