Community
Participate
Working Groups
For the latest I-Build I tagged most every Equinox project to include the following commit: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=312a4b51a28247c5dd863ce375158910eb5650f8 I know many of these bundles has not changed their version yet for the Juno release. For example, org.eclipse.equinox.event was version 1.2.100.v20110502 in Indigo, but now is 1.2.100.v20111010-1614 in the latest I-Build (I20111011-1046). I would have expected the version report tool to complain that org.eclipse.equinox.event should increment its version to at least 1.2.101. This is not being reported at: http://download.eclipse.org/eclipse/downloads/drops/I20111011-1046/testresults/versiontool/results.xml
Kim have you had any chance to look at this?
Is this still an issue? I think I changed the build to compare against 3.7.1 a while ago.
I looked at the results of the I20111213-1443 build and these are the 3 errors/warnings. The 2 errors listed seem to indicate that we have breaking API changes. Tom, is this true? The 1 warning is missing the change type so I'm not sure what we need to do to resolve the problem. Errors: The version of the feature (id: "org.eclipse.equinox.serverside.sdk"; version: "3.8.0.v20111114-2124-9Q7dFb8FRWt32-_vXXd00E_nXdDG") should be at least "4.0.0"."/> The version of the feature (id: "org.eclipse.equinox.sdk"; version: "3.8.0.v20111010-1614-7M7f8Z8fy_d3DGDmLU05dewRthpE) should be at least "4.0.0" Warning: Feature (id: "org.eclipse.equinox.server.jetty"; version: "1.1.0.v20111206-1542-8077BgD-hQ888B5A47FGA") got "" change, but its "Minor" version has been increased.
These problems were fixed in I20111230-0735. DJ, these are not breaking API changes, they are a result of the new jetty bundles etc. I changed the releng tools to ignore those bundles.
We still don't have a tool or report that warns about bundles with outdated bundle versions. Given that this causes grief during ever release we should provide such a report. I can share the current state of my bundle checker if you want.
Untargeting for specific milestone, since not sure which milestone I'll finish this in.
I'm sure I documented this somewhere, but I guess not in this bug. While we do not have "tests" yet that will flag when a bundle or feature needs updating we do produce "repository reports" for each build. Unfortunately for Oxygen M1 we were still using the 4.6 release as the "reference" instead of the latest M-build. For M-builds, the 4.6 release is the correct reference repository through Neon.1. These are linked near the top of each "logs for the current build.". http://download.eclipse.org/eclipse/downloads/drops4/S-4.7M1-201608032000/testResults.php For example, for the latest milestone, for features see http://download.eclipse.org/eclipse/downloads/drops4/S-4.7M1-201608032000/buildlogs/reporeports/reports/versionChecksFeatures.html for bundles see http://download.eclipse.org/eclipse/downloads/drops4/S-4.7M1-201608032000/buildlogs/reporeports/reports/versionChecks.html For the latest M-build, see the links under http://download.eclipse.org/eclipse/downloads/drops4/M20160803-1700/buildlogs/reporeports/index.html The worst case to watch for is if a version "decreases" compared to its reference. But also, any feature or bundle that increases "qualifier only" means that at least its service field needs to be increased (and in some cases, the minor field, depending on what has changed. I realize this is a laborious check to do "by hand" but the goal is eventually to run these as "releng tests". I believe, thanks to Dennis Hubner, some of these can be run as JUnit tests but I have never had time to look at the work he has done. And while the I-builds, for now, need a "manual" update to the reference repository, eventually that could probably be automated. Given that "Neon.1" is the next release, there should be plenty to look at for the M-builds. Also, remember, if a feature has a "branding bundle" the branding bundle needs to have its version incremented to match the version of the feature.
I did fix bug 499157 so from now on, each I-build should use the latest M-build as the "reference" repository. The fix only uses "good" repositories that get promoted to "downloads" (in some cases a repo might be created on "builds" but then we notice the build failed for other reasons so that repo is not promoted to downloads. Obviously, if an M-build is found to be "completely wrong" the "latest repo" may need to be removed, or renamed so it does not match the "name pattern" of "M20*". And, yes, the biggest need is to convert to "unit tests" so we get an obvious "signal" to fix versions ... but, I'll leave that to Sravan. :) or other volunteers! (again, I think basics are there in the tool, but I have not looked at that part to see what it would take).
Doing a mass "reset to default assignee" of 52 bugs to help make clear it will (very likely) not be me working on things I had previously planned to work on. I hope this will help prevent the bugs from "getting lost" in other people's queries. Feel free to "take" a bug if appropriate.
Retargetting to 4.8. We won't be able to look into this in 4.7
bug 522223 covers the story and has already successfully warned during CI/Gerrit builds about erroneous versions. *** This bug has been marked as a duplicate of bug 522223 ***
This got fixed a while ago with the Bundle versions compared to reference repository report.
