Bugzilla – Full Text Bug Listing
| Summary: | "calculate version id" should use only number of fields supplied. | ||
|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | David Williams <david_williams> |
| Component: | Build | Assignee: | pde-build-inbox <pde-build-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
The feature.xml is a billing list of material that tells update what must be downloaded. Putting approximate values is not possible since update would not know what to download (this would be particularly problematic if multiple versions of the same feature was available on the server). At best what PDE Build can do is support 0.0.0 or 0.0.0.0 as placeholders. Would that help you? On the precise example you gave, if you are reconsumming xerces straight out of apache then you should not "qualify" it since it never changes. The only time it will change is when you will take another version from apache in which case the manifest will have a new version. Another example to that in the eclipse SDK is Ant that we ship has org.apache.ant. If you are modifying / adding code into xerces, then it should not be named org.apache.xerces, but something like org.eclipse.xerces. And finally a question: why do you still ship xerces since 1.4 includes an XML parser. >The feature.xml is a billing list of material that tells update what must be
>downloaded"
Ok, maybe I've misunderstood. I thought update manager would use the actual plugin requirements, combined with feature's recomendation, to get "best version" and "most recent" version that matched all the criteria. Mabye its working as best it can, but I just found it odd that a new feature.xml file would be *required* for every time a plugin changed the 4th place version number.
On the two xerces questions:
1. I thought best to use 4th qualifier since, even if the third party code doesn't change, sometimees we have to do an update when we find that we've forgotten to externalize some plugin name, or minor corrections to the about.html file, etc. It would be expected to almost never change, but, if we didn't allow for it at all, then we couldn't really use it to do "milestone updates", etc.
2. we use some 'xml validation' functions in xerces that are not in the JRE DOM packages. (or, more correctly, the xerces versions are more up to date, or more advanced).
Closing as wontfix since 0.0.0 is used as a special marker and udpate can't use approximate version numbers. I'm not sure what you mean by "udpate can't use approximate version numbers". Perhaps you mean for "includes"? What happens with update and "requires"? We use "requires" in a number of our features, even within our two WTP projects, because in some scenerios the "prereqs" may already be installed by other "products". Maybe I'm still not seeing this right, or, maybe there's a better way to say it, but ... If I have a "common.feature" and it includes a "common.plugin" and they both use the "qualifer" to be marked during build with cvs map version, and the feature uses "0.0.0" to be filled in automatically during the build. so, let's say on 20060101, both feature and plugin are modified, and built, so they all have a version of, say 1.0.0.v20060101, and the feature includes plugin version 1.0.0.v20060101. Now, a few days later, the plugin is modified, so its version becomes 1.0.0.v20060105. (but, the feature is not modified, so its version remains at 0101). But, at this point, I think, there's a problem because the "latest" feature still says to use plugin 1.0.0.v20060101? Like I said, I'm probably misunderstanding how things really work, and have not literally ran into a problem (since just working with zips, so far) but ... would appreciate some clarification. Thanks. Is this not a problm because there's an implied assumption that every feature built, will "overlay" any feature on update site, even if *its* version is identical, just because its "included" versions might have changed? Feature version numbers are computed based on the things they include. In your scenario, when you built the new version of the plugin, you had two choices, 1) you could either biuld just the plugin and put it on an update site or 2) build the feature and put it on the update site. 1) This is fine BUT, since you did not build the feature, the update site will not contain any feature that lists the new plugin so the fact that it is there is moot. No one will ever be able to install it. 2) If you build the feature the feature qualifier will be generated based on the versions of the things it includes. So if the plugin changed, the feature version number will also change. Put both of these on the update site and people can see the new feature and thus get the new plugin. Note alos that if you the contents of the feature did not change then the version number of the feature (and its contents for that matter) would not change so the whole operation was essentially a no-op. In comment 4 you mention some confusion about "approximate version numbers". Perhaps this is the key. Features, for better or worse, identify EXACTLY the plugins/features that are included. There is no fuzziness, ranges or matching. What you see is what you get. If you are *requiring* then you get to specify some fuzziness. In this case since installing the requiring feature does not imply an installation of the required features/plugins, fuzziness is fine. This is a known issue that has been in place forever and we hope to do something about it in the future but for 3.2, that's it. Did that help or hinder? It helps, the part I did not realize was "If you build the feature the feature qualifier will be generated based on the versions of the things it includes." That would work just fine for us, but did not realize it worked that way (I was assuming there was just a "dumb" rule to fill in the qualifier from the map version of the feature itself. Thanks. yeah, Andrew and Pascal came up with a cool algorithm for generating a qualifier with all the right characteristics. Actually, of topic a bit but does that algorithm take into account the CVS tag of the feature itself? It probably should since if something in the feature itself changes, the qualifier should change... When using ".qualifier", the resulting feature version can take the form of 1.2.3.qualifier_suffix, where qualifier will come from the cvs tag, or date the same as for plugins. suffix will be generated based on the qualifiers of the contained plugins. Whether or not to append the _suffix to the version is controlled by the property "generateFeatureVersionSuffix" in the builder's build.properties. The default value is false. Closing as there is nothing to do here. |
Seems to me, that the handy trick of using "0.0.0" in feature.xml, as an indication that the version ID should be calculated automaticlly during build process, should be "masked" by how many zero's are supplied. With the plugin versioning process, where we use ".qualifer" at the end of plugin version numbers (which are filled in by map tags), it makes the feature.xml files overly specific to include all 4 digits automatically. I would have expected it to include only 3 digits (or .. even only two, if only 2 zeros supplied). To give a concrete example, in our xerces feature, we have <plugin id="org.apache.xerces" download-size="0" install-size="0" version="0.0.0"/> but after the build, this get's translated to <plugin id="org.apache.xerces" download-size="0" install-size="0" version="2.7.0.v20060128_1458"/> I'm not sure if there's any advantages or disadvantages to one or the other .. but .. sure seems confusing to me. (and, if 4 places were desired, then user could simply specify "0.0.0.0" to get all four fields calculated).