Thanks for the input, guys. I didn't know about the different interpretation of this in feature.xml.
I guess I will stick with the explicit version ranges.
What makes me sad is that I won't be able to use [1] and be done. Every time I upgrade the version I will also have to manually (although I can script it, sure) change all the manifests.

-Martin

[1] mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=<version> (https://community.jboss.org/en/tools/blog/2011/09/17/coping-with-versions-in-large-multi-module-osgi-projects)

On 4. 10. 2013, at 17:48, Nick Boldt <nboldt@redhat.com> wrote:

It's always better to be explicit, because in plugin manifests "0.4.0" means "0.4.0+" and in feature manifests (feature.xml) it means "[0.4.0,1.0.0)". This is easy to forget, which is why I recommend being explicit, or else bookmarking this blog:

http://divby0.blogspot.ca/2011/07/manifestmf-and-featurexml-versioning.html

:D

On 10/04/2013 09:23 AM, Mickael Istria wrote:
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 <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>


_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev


--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com

--
Martin Malina
JBoss QA Engineer
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno, Czech Republic

Tel.: +420 532 294 265