Community
Participate
Working Groups
The set-version plugin does not update version referenced from requires/import feature elements in feature.xml.
originally reported as https://dev.eclipse.org/mhonarc/lists/tycho-user/msg06776.html this is a version range scenario similar to bug 477328
The feature.xml>requires>import element does not use osgi version ranges for referencing a version. It uses 2 attributes. Extract from http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Ffeature_manifest.html&cp=2_1_5_20 * version - optional plug-in version specification. * match - optional matching rule. Valid values and processing are as follows: if version attribute is not specifies, the match attribute (if specified) is ignored. * perfect - dependent plug-in version must match exactly the specified version. If "patch" is "true", "perfect" is assumed and other values cannot be set. * equivalent - dependent plug-in version must be at least at the version specified, or at a higher service level (major and minor version levels must equal the specified version). * compatible - dependent plug-in version must be at least at the version specified, or at a higher service level or minor level (major version level must equal the specified version). * greaterOrEqual - dependent plug-in version must be at least at the version specified, or at a higher service, minor or major level. If we want to keep things consistent with bug 477328 we could do the following: * When a requires>import element references an element (feature or plugin) that becomes unsatisfied due changes made by set-version the version should be updated to keep the import satisfied. * Additionally if the property "updateVersionRangeMatchingBounds" is set to true. import element version should be updated if it was matching the major.minor.micro part of the version even if it is still satisfied.
(In reply to Sebastien Arod from comment #2) > If we want to keep things consistent with bug 477328 we could do the > following: > > * When a requires>import element references an element (feature or plugin) > that becomes unsatisfied due changes made by set-version the version should > be updated to keep the import satisfied. > > * Additionally if the property "updateVersionRangeMatchingBounds" is set to > true. import element version should be updated if it was matching the > major.minor.micro part of the version even if it is still satisfied. +1
Any news about this bug ?
I'll try to work on this this week.
I published a fix on gerrit but it doesn't appear on this bug. https://git.eclipse.org/r/#/c/62347/
(In reply to Sebastien Arod from comment #6) > I published a fix on gerrit but it doesn't appear on this bug. > https://git.eclipse.org/r/#/c/62347/ If you prefix the first line of the commit message with "Bug: <number>" the bot will cross-link bug and proposed gerrit change. I just updated https://wiki.eclipse.org/Tycho/Contributor_Guide#Commit_Message_Guidelines accordingly
(In reply to Jan Sievers from comment #7) > (In reply to Sebastien Arod from comment #6) > > I published a fix on gerrit but it doesn't appear on this bug. > > https://git.eclipse.org/r/#/c/62347/ > > If you prefix the first line of the commit message with "Bug: <number>" the > bot will cross-link bug and proposed gerrit change. I just updated > https://wiki.eclipse.org/Tycho/Contributor_Guide#Commit_Message_Guidelines > accordingly according to bug 465045, "Bug: <number>" at the end of the commit message should work too. so looks like you just missed a colon.
The colon in the message footer was the issue. Thanks
Gerrit change https://git.eclipse.org/r/62347 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/commit/?id=a0e008d590b903003f4f6dae9cd97aed6c608762
thanks for the patch! I guess we should have a short description of this feature in the release notes https://wiki.eclipse.org/Tycho/Release_Notes/0.25
