<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 10. 10. 2013, at 13:57, Max Rydahl Andersen <<a href="mailto:manderse@redhat.com">manderse@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thu, Oct 10, 2013 at 12:30:35PM +0200, Martin Malina wrote:<br><blockquote type="cite">Thanks for the input, guys. I didn't know about the different interpretation of this in feature.xml.<br>I guess I will stick with the explicit version ranges.<br>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.<br></blockquote><br>eh ?<br><br>[1] updates all occurence of your project versions - including manifest.<br></blockquote><div><br></div><div>It updates version in manifest of the bundle itself, but not version of required bundles - obviously: it wouldn't know which bundles are part of the same project.</div><div>And the conclusion of this thread is that it probably makes sense for us to keep these requirements strict, including version ranges.</div><div><br></div><br><blockquote type="cite"><br>Aren't your problem about when you need to update projects that rely on red deer release ?<br></blockquote><div><br></div>No, this thread had nothing to do with other projects relying on reddeer - although we could restrict the requirements there, too. But here I was only asking with respect to the reddeer project alone - most reddeer bundles rely on other reddeer bundles.</div><div><br></div><div>-Martin</div><div><br><blockquote type="cite"><br>Thats where API compatibility becomes relevant ;)<br><br>/max<br><br><blockquote type="cite">-Martin<br><br>[1] mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=<version> (<a href="https://community.jboss.org/en/tools/blog/2011/09/17/coping-with-versions-in-large-multi-module-osgi-projects">https://community.jboss.org/en/tools/blog/2011/09/17/coping-with-versions-in-large-multi-module-osgi-projects</a>)<br><br>On 4. 10. 2013, at 17:48, Nick Boldt <<a href="mailto:nboldt@redhat.com">nboldt@redhat.com</a>> wrote:<br><br><blockquote type="cite">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:<br><br><a href="http://divby0.blogspot.ca/2011/07/manifestmf-and-featurexml-versioning.html">http://divby0.blogspot.ca/2011/07/manifestmf-and-featurexml-versioning.html</a><br><br>:D<br><br>On 10/04/2013 09:23 AM, Mickael Istria wrote:<br><blockquote type="cite">On 10/04/2013 02:09 PM, Martin Malina wrote:<br><blockquote type="cite">in<br>https://github.com/jboss-reddeer/reddeer/blob/master/plugins/org.jboss.reddeer.eclipse/META-INF/MANIFEST.MF<br></blockquote>Keep in mind that "0.4.0" means [0.4.0, 2147483647.2147483647.2147483647].<br>Eclipse guidelines say that since only major version bump should cause<br>API incompatibility, it's better to use ranges such as "[0.4.0,1.0.0)"<br>since 1.0.0 and later wouldn't be compatible with 0.x.<br><br><blockquote type="cite">The reasoning for this version setting is to eliminate the risk of<br>mixing different versions of RedDeer bundles that you may have<br>installed in your local repository. What do you think about this? I<br>didn't see any such thing in jbosstools source so I wonder if this is<br>a real threat.<br></blockquote>On the other end, it prevents any of this bundle to run with older<br>version of RedDeer, even if it's possible to mix them. It's a trade-off<br>between modularity and compatibility<br>As we usually ship bundles in features, and that features contain the<br>exact qualified version of the bundles to install, adding these<br>constraints is not very helpful for the normal installation scenario as<br>features provide much stricter constraints. However, if you don't use<br>feature includes, and only rely on feature "imports" and MANIFEST.MF<br>Require-Bundle to resolve dependencies, such change gives good hints.<br><br>Anyway, that's a very good question you have there, and there is a very<br>elegant answer in PDE: http://www.eclipse.org/pde/pde-api-tools/ . With<br>API Tools enabled in your IDE, you'll be able to annotate your APIs and<br>PDE will give you hints on how to deal with versions compared to a<br>baseline, depending on the API change you make. Also, if you depend on<br>newer APIs from another bundle, it will tell you to change the version<br>in your dependencies to the minimal version which provides this API.<br><br>HTH<br>--<br>Mickael Istria<br>Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools><br>My blog <http://mickaelistria.wordpress.com> - My Tweets<br><http://twitter.com/mickaelistria><br><br><br>_______________________________________________<br>jbosstools-dev mailing list<br>jbosstools-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/jbosstools-dev<br><br></blockquote><br>--<br>Nick Boldt :: JBoss by Red Hat<br>Productization Lead :: JBoss Tools & Dev Studio<br>http://nick.divbyzero.com<br></blockquote><br>--<br>Martin Malina<br>JBoss QA Engineer<br>Red Hat Czech s.r.o.<br>Purkynova 99<br>612 45 Brno, Czech Republic<br><br>Tel.: +420 532 294 265<br><br><br><br><br></blockquote><br><blockquote type="cite">_______________________________________________<br>jbosstools-dev mailing list<br><a href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/jbosstools-dev<br></blockquote><br></blockquote></div><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 12px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Martin Malina<br>JBoss QA Engineer<br>Red Hat Czech s.r.o.<br>Purkynova 99<br>612 45 Brno, Czech Republic<br></div><div><br></div><div><span class="Apple-style-span" style="font-size: medium; ">Tel.: +420 532 294 265</span></div><div><span class="Apple-style-span" style="font-size: medium; "><br></span></div></div></span></div></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br></body></html>