<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 10/04/2013 02:09 PM, Martin Malina
      wrote:</div>
    <blockquote
      cite="mid:E6AD70A1-F31C-4DC6-8C7A-7144E6140A60@redhat.com"
      type="cite">
      <div>in&nbsp;<a moz-do-not-send="true"
href="https://github.com/jboss-reddeer/reddeer/blob/master/plugins/org.jboss.reddeer.eclipse/META-INF/MANIFEST.MF">https://github.com/jboss-reddeer/reddeer/blob/master/plugins/org.jboss.reddeer.eclipse/META-INF/MANIFEST.MF</a></div>
    </blockquote>
    Keep in mind that "0.4.0" means [0.4.0, <span class="cwcot"
      id="cwos">2147483647</span>.<span class="cwcot" id="cwos">2147483647</span>.<span
      class="cwcot" id="cwos">2147483647].<br>
      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.<br>
      <br>
    </span>
    <blockquote
      cite="mid:E6AD70A1-F31C-4DC6-8C7A-7144E6140A60@redhat.com"
      type="cite">
      <div>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.</div>
    </blockquote>
    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. <span
      class="Apple-style-span" style="border-collapse: separate;
      border-spacing: 0px; ">It's a trade-off between modularity and
      compatibility<br>
      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.<br class="Apple-interchange-newline">
    </span><br class="Apple-interchange-newline">
    Anyway, that's a very good question you have there, and there is a
    very elegant answer in PDE:
    <a class="moz-txt-link-freetext" href="http://www.eclipse.org/pde/pde-api-tools/">http://www.eclipse.org/pde/pde-api-tools/</a> . 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.<br>
    <br>
    HTH<br>
    <div class="moz-signature">-- <br>
      Mickael Istria<br>
      Eclipse developer at <a href="http://www.jboss.org/tools">JBoss,
        by Red Hat</a><br>
      <a href="http://mickaelistria.wordpress.com">My blog</a> - <a
        href="http://twitter.com/mickaelistria">My Tweets</a></div>
  </body>
</html>