[jbosstools-dev] Required bundles and version restriction

[Max Rydahl Andersen]

On Thu, Oct 10, 2013 at 12:30:35PM +0200, Martin Malina wrote:
>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.

eh ?

[1] updates all occurence of your project versions - including manifest.

Aren't your problem about when you  need to update projects that rely on red deer release ?

Thats where API compatibility becomes relevant ;)

/max

>-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 at 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 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
>
>--
>Martin Malina
>JBoss QA Engineer
>Red Hat Czech s.r.o.
>Purkynova 99
>612 45 Brno, Czech Republic
>
>Tel.: +420 532 294 265
>
>
>
>

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