Community
Participate
Working Groups
I did a build specifically to check, when nothing in map files changed, that no qualifiers did ... but, found one, org.xmlpull that did. This has to do with the "fourth part + qualifier" pattern. I'll have to check the references on what the right pattern is ... but, we don't want qualifiers changing every build. $ diff I20111224154307list.txt I20120105171922list.txt 538c538 < org.xmlpull_1.1.3.4_201112241601.jar --- > org.xmlpull_1.1.3.4_201201051737.jar
This happened recently as discussed in bug 355586. At that time, I added a bit more instructions to http://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit I have now added a 'header' to that section so that a) it stands out, and b) make it easier to refer to :) http://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit#Avoid_qualifiers_that_change_with_date_and_time_of_each_build
I think in this case, it is the feature.xml file that needs tweeking, to add the 4th segment, such as <plugin id="org.xmlpull" download-size="0" install-size="0" version="1.1.3.4_qualifier" unpack="false"/> Plus, "touching" (tagging) the org.xmlpull module with date and time of "fix", will be required, to make sure the qualifier always increments. Otherwise, the change in the feature.xml file will case the qualifier to go "down" based on an "old" cvs timestamp. Let me know if unclear or your need help.
I'm going to go ahead and try to fix this (I want to get a build promoted with the fix, today).
Changed feature.xml (tagged, and updated map file) and tagged xmlpull with v201201052148 So, now, qualifier should be 4_v201201052148 each build ... I think :/
The I20120105215809 build did have the jar versioned as expected: org.xmlpull_1.1.3.4_v201201052148.jar So, I think it will stay that way from build to build, unless changed in CVS and retagged. Let me know if any concerns ... it is sort of an odd pattern ... (and, I guess the "v" would have made it "greater than" anything that came before, by coincidence that 'v' is greater than '2') but I think this is the best way to handle cases where there are already 4 segments (that is, still a valid qualifier that stays the same from build to build, but can increase in future, if changes needed and the module retagged). Thanks,
