The xulrunner have some weird versioning I would like to get cleaned up or at least documented why it is so: The bundle manifests uses three different versions: Bundle-Version: 1.9.2.16 this is original XR binaries Bundle-Version: 1.9.2.16b this is slightly changed original binaries for Windows and Linux x86. I have added 'b' while modifying these plugins. Bundle-Version: 1.9.2.19pre this is binaries from XR nightly builds for Linux x86_64, it works the best on Linux x86_64

The feature uses a "merged" version in 2 different shapes: /features/org.mozilla.xpcom.feature/feature.xml: version="1.9.216.qualifier" ./features/org.mozilla.xulrunner.feature/feature.xml: version="1.9.218.qualifier" 218 should be just a typo. Probably we it would be better if we leave 1.9.2.qualifier

Questions for Yahor/Denis: 1) Does these ever change ? if yes then they should have .qualifiers in the manifest Yes, Denis and I are trying to keep it updated.

2) Any reason why a mix of .16/.16b/.19pre and 216/218 ? Yes, see above. Different OSs need different XR versions. I will add comments to poms.

/max http://about.me/maxandersen _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev --Yahor

On 07/28/2011 07:41 AM, Max Rydahl Andersen wrote: >> The xulrunner have some weird versioning I would like to get cleaned up or at least documented why it is so: >> >> The bundle manifests uses three different versions: >> >> Bundle-Version: 1.9.2.16 >> this is original XR binaries >> Bundle-Version: 1.9.2.16b >> this is slightly changed original binaries for Windows and Linux x86. I have added 'b' while modifying these plugins. >> Bundle-Version: 1.9.2.19pre >> this is binaries from XR nightly builds for Linux x86_64, it works the best on Linux x86_64 > >> The feature uses a "merged" version in 2 different shapes: >> >> /features/org.mozilla.xpcom.feature/feature.xml: version="1.9.216.qualifier" >> ./features/org.mozilla.xulrunner.feature/feature.xml: version="1.9.218.qualifier" >> 218 should be just a typo. Probably we it would be better if we leave 1.9.2.qualifier > eh ? no �why not 1.9.2.18.qualifier ? hmm i guess osgi doesn't like that. No, leave .216 and/or .218 so we know that it aligns with included plugin versions. And yes, we can't have a 5-part version under osgi rules, which is why I started using this a.b.cd.qualifier feature version for a.b.c.d plugins.

Reverting to .2 would be bad -- must go forward, not backward. "If it ain't broke..." :) > Any how - we need to be careful about such changes since might not be possible to install via p2 if sudden change in sequence of version number. > >> >> Questions for Yahor/Denis: >> >> 1) Does these ever change ? if yes then they should have .qualifiers in the manifest >> Yes, Denis and I are trying to keep it updated. > > So what part of the version number do you bump on changes ? > >> 2) Any reason why a mix of .16/.16b/.19pre and 216/218 ? >> Yes, see above. Different OSs need different XR versions. I will add comments to poms. > > ok. thanks. > > /max > >> >> /max >> http://about.me/maxandersen >> >> >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> --Yahor > > /max > http://about.me/maxandersen > > > > > _______________________________________________ > jbosstools-dev mailing list > 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 jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev