Community
Participate
Working Groups
As I understand it, the plugin version qualifier (that is the last "vnnnnnnnn" portion of the plugin version) should get updated when the plugin is built, regardless of whether the source of the plugin has changed or not. That does not appear to be happening. For at least one plugin (org.eclipse.datatools.modelbase.sql.query.edit), the plugin qualifier has not changed since DTP 1.7.2 (v200906022249) while the plugin has in fact been rebuilt for each subsequent release (1.8, 1.8.1, 1.8.2). Due to changes in the underlying code referenced by the plugin (platform and EMF), the binary code in the plugin is different from the 1.7.2 version. This difference has caused a bug in the product IBM Rational Application Developer. Please modify the build process so that the plugin version qualifier gets updated when the plugin is rebuilt for any reason.
DTP follows the same versioning policy as platform team, which is also a build requirement of the simultaneous release.(http://wiki.eclipse.org/Version_Numbering#When_to_change_the_qualifier_segment) The 4th part of plugin version (.qualifer) represents the last content commit date of that plugin not the build time. And update manager/p2 will take advantage of that value to check if there is any updates on the site. If the 4th part version remains same, the update manager/p2 will not download the binary jar, which will reduce the update time and network resources. Since current DTP build policy is using the "I-build" as all nightly,integration,milestone builds, hence the 4th part of plugin version gets its value from the tag name defined in map files, which is not decided by the build process itself. I think it does make sense to upgrade the [major].[minor].[service] segment of all DTP plugins for each main release. For example, for dtp 1.8.x, all plugins should update their MANIFEST.MF to use 1.8.0.qualifer, which also fix the issue described in the summary. Since the build environment does have the possibility to change between two main release.
I contacted Boris Bokowsky of the platform team, and he directed me to Kim Moir, who does platform release engineering. According to them, there are two cases where plugins are tagged and map files get updated, thus generating a new plugin version qualifier. One is the usual case where the source code has been updated. The other is if there is a change in the build process that results in the generated binaries being different, such as a new version of the Java compiler. According to Kim, the platform team has a comparator and test in their build process so they get notified if the binaries have changed so they can re-tag the bundles. I asked if those tools are available, but haven't heard back yet.
Regarding updating the plugin version for all plugins for each release: the versioning guidelines explicitly say to not do that. Plugin versions should follow changes to that particular plugin, not the project or release as a whole. The answer here is to re-tag and update the map files whenever there is a change that affects the generated binaries, whether it comes from a source change or a build environment change. We should have updated all the map files when we moved to the newer JDK.
(In reply to comment #3) > Regarding updating the plugin version for all plugins for each release: the > versioning guidelines explicitly say to not do that. Plugin versions should > follow changes to that particular plugin, not the project or release as a > whole. > > The answer here is to re-tag and update the map files whenever there is a > change that affects the generated binaries, whether it comes from a source > change or a build environment change. We should have updated all the map files > when we moved to the newer JDK. We did not change the build environment since dtp 1.7.2. The dtp binary was built with Eclipse 3.4.2 SDK, EMF 2.4.2 (EMF + SDO) and GEF 3.4.2 and jdk1.5.0_09. So what's the status of this bug?
1.9.0 build was built based on Eclipse 3.6.1 SDK, EMF 2.6.1 (EMF + SDO), GEF 3.6.1, but the JDK version was same as 1.7.x/1.8.x.
OK, we've determined that the problem appears to be limited to the plugin o.e.d.modelbase.sql.query.edit. This looks like what happened: the change for Bug 302917 in DTP 1.8 that refreshed the some of the modelbase plugins also changed the binary for plugin o.e.d.modelbase.sql.query.edit, but it was not tagged as changed. I'll re-tag the plugin and update the map file.
OK, I've tagged plugin o.e.d.modelbase.sql.query.edit to v201105201100 and updated the map file.
