Re: [jbosstools-dev] Required bundles and version restriction

Yes, for a plugin, 1.2.3 == [1.2.3,999.999.999]. For a feature, unbounded defaults to "compatible", or [1.2.3,2.0).

Because the defaults are different in the different contexts (plugin vs. feature) I would still rather see it spelled out than assumed.

But as in all things, YMMV. On 10/07/2013 08:55 AM, Max Rydahl Andersen wrote: >On Fri, Oct 04, 2013 at 11:48:01AM -0400, Nick Boldt 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 >> > >You should read your own blog ;) > >0.4.0 means: "An “unbounded” version range, such as 1.2.3, which denotes >version 1.2.3 and all later versions." >Meaning it doesn't stop at 1.0.0. > >/max > >>: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 &gt;&gt;&gt;jbosstools-dev(a)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 >>_______________________________________________ >>jbosstools-dev mailing list &gt;&gt;jbosstools-dev(a)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