On 10/04/2013 02:09 PM, Martin Malina wrote:
in https://github.com/jboss-reddeer/reddeer/blob/master/plugins/org.jboss.reddeer.eclipse/META-INF/MANIFEST.MF
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
My blog - My Tweets