[jbosstools-dev] Required bundles and version restriction

[Max Rydahl Andersen]

On Mon, Oct 07, 2013 at 12:49:52PM -0400, Nick Boldt wrote:
>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.

ah yes - damn inconsistent feature.xml's...wish they could go away ;)

/max

>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
>>>>jbosstools-dev at 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
>>>jbosstools-dev at 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