On 10/04/2013 02:09 PM, Martin Malina wrote:
Keep in mind that "0.4.0" means [0.4.0,
2147483647.2147483647.2147483647].
Eclipse guidelines say that since only major version bump should cause
API incompatibility, it's better to use ranges such as "[0.4.0,1.0.0)"
since 1.0.0 and later wouldn't be compatible with 0.x.
The reasoning for this version setting is to eliminate the risk of
mixing different versions of RedDeer bundles that you may have
installed in your local repository. What do you think about this? I
didn't see any such thing in jbosstools source so I wonder if this is
a real threat.
On the other end, it prevents any of this bundle to run with older
version of RedDeer, even if it's possible to mix them. It's a trade-off
between modularity and compatibility
As we usually ship bundles in features, and that features contain the
exact qualified version of the bundles to install, adding these
constraints is not very helpful for the normal installation scenario as
features provide much stricter constraints. However, if you don't use
feature includes, and only rely on feature "imports" and MANIFEST.MF
Require-Bundle to resolve dependencies, such change gives good hints.
Anyway, that's a very good question you have there, and there is a very
elegant answer in PDE:
http://www.eclipse.org/pde/pde-api-tools/ . With
API Tools enabled in your IDE, you'll be able to annotate your APIs and
PDE will give you hints on how to deal with versions compared to a
baseline, depending on the API change you make. Also, if you depend on
newer APIs from another bundle, it will tell you to change the version
in your dependencies to the minimal version which provides this API.
HTH
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <
http://www.jboss.org/tools>
My blog <
http://mickaelistria.wordpress.com> - My Tweets
<
http://twitter.com/mickaelistria>