Bugzilla – Full Text Bug Listing
| Summary: | Cannot find update site for Juno SR2 bits | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Anthony Hunter <ahunter.eclipse> |
| Component: | RelEng | Assignee: | gef-inbox <gef-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bugs.eclipse.org, ccc, david_williams, irbull, mknauer, nyssen, pierre-charles.david, stephen.francisco |
| Version: | 3.8 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Anthony Hunter
Actually the interim site seems to be functional, but it doesn't contain the particular GEF 3.8.2 build. Looking in /interim I see the following 3.8.2 versions of the org.eclipse.gef feature: id=org.eclipse.gef.feature.group ver=3.8.2.201210130206 id=org.eclipse.gef.feature.group ver=3.8.2.201210200206 id=org.eclipse.gef.feature.group ver=3.8.2.201210270205 id=org.eclipse.gef.feature.group ver=3.8.2.201212010305 id=org.eclipse.gef.feature.group ver=3.8.2.201212080305 id=org.eclipse.gef.feature.group ver=3.8.2.201212150305 id=org.eclipse.gef.feature.group ver=3.8.2.201212220305 id=org.eclipse.gef.feature.group ver=3.8.2.201301050304 id=org.eclipse.gef.feature.group ver=3.8.2.201301190305 id=org.eclipse.gef.feature.group ver=3.8.2.201301250307 however the version that seems to be the GA version is 3.8.2.201301120305 which isn't in that list. The version being used in the GA should not be contained on the interim update-site (which takes the weekly integration builds, that are promoted automatically) but on the milestones update-site (which I manually promoted it to). It is the RC1 milestone build, which resulted out of Hudson job get-maintenance #212. As the build server is currently down, I could not yet promote it to the releases update site as well, but I will do so as soon as webmaster has completed the restore. I can confirm 3.9 is in Juno SR2 site. Such as org.eclipse.gef.sdk_3.9.0.201212170307.jar How bad is that? I suspect these were used in EPP packages as well. Are they that different? This shouldn't be. The gef version to be used in the GA build is 3.8.2.201301141834, which is the one I have specified in the gef.b3aggrcon (within the Juno_maintenance branch of the org.eclipse.semrel.build.git); it corresponds to the RC1 lease I promoted to the milestones update site. How can that be? Yes, but you specified the site as http://download.eclipse.org/tools/gef/updates/milestones Which does have 3.8.2.201301141834 but also some from "3.9". Since you specified the feature as <features name="org.eclipse.gef.sdk.feature.group" versionRange="3.8.2.201301141834"> That means "3.8.2.201301141834 or higher" ... so ... looks like it took the "higher" route. As p2 nearly always does. (In reply to comment #5) > Yes, but you specified the site as > http://download.eclipse.org/tools/gef/updates/milestones > > Which does have 3.8.2.201301141834 but also some from "3.9". > > Since you specified the feature as > > <features name="org.eclipse.gef.sdk.feature.group" > versionRange="3.8.2.201301141834"> > > That means "3.8.2.201301141834 or higher" ... so ... looks like it took the > "higher" route. As p2 nearly always does. Yes, the milestone site contains all our milestones builds, which includes 3.8.2 as well as 3.9.0 builds. I thought a range without a range points to an exact version. And why has this not happened earlier? The gef.b3aggrcon file seems to have always been looking like this, there never was a version range specified. I can change it to [3.8.2.201301141834, 3.9.0)? What are we going to do about the GA? I changed the get.b3aggrcon to use [3.8.2.201301141834, 3.9.0) for gef and [1.4.2.201301141834, 1.5.0) for zest instead of the prior non-ranged versions. To answer your question, David, the changes are rather small (fixes for bugs #388697, #394137, #395872), but the version ranges have been increased to 3.9.0 for gef as well as 1.5.0 for zest. Even if the GA participants are not directly affected by this, I think third-party may be disturbed by finding a gef 3.9 and a zest 1.5 within the Juno SR2. I apologize for any inconvenience... (In reply to comment #6) > (In reply to comment #5) > What are we going to do about the GA? My advice, off hand, since you say "not much difference" is to support both! Provide your own 3.8.2 version as you planed and that be the one available from your own GEF repo site ... but if someone comes along with a bug for "juno" and they say that have that particular 3.9.0 version for you help fix. (And, you'd have to "save" the 3.9.0 version somewhere, so you could provide a patch or something). I think the general advice and practice is that adopters get their content from project's specific sites, so they'd still get 3.8.2, not mess up their translation fragments, etc., but I can imagine scenarios where end-users (customers of third parties) end up with the 3.9 version. Not sure. I know if a "product" usually contains constraining feature definitions so if a third party "did it right", their users would always have 3.8.2 version. But, doesn't help third parties that provide "plugins" on top of SDK say, and specify a wide range for GEF. I'm hesitant to "stop ship" without a concrete blocking, known issue, since to stop ship at this point would mean a week's delay. Its not something to fix overnight, or even over a weekend. It looks like the final GEF version for Juno SR2 should be 3.8.2.201301141834. We were under the impression is was 3.8.2.201301120305. I suppose we can pick up the 201301141834 zip files instead, but the larger issue seems to be that GEF 3.9.0 is showing up in the Juno/SR2 repository. As far as I know we've been testing Juno SR2 assuming GEF 3.8.2 is the version to include, so I don't want to just step up to 3.9.0. My vote (if anyone cared) would be to make sure the intended GEF version 3.8.2 is in Juno SR2, and not 3.9.0. Even if the changes are minor, the version change will break the translation fragments that we have created since they are for version [3.8.2,3.9.0) Two observations first: (1) The GEF *feature*: * (Looking back to Juno SR1: You were shipping 3.9.0.201208201742 - i.e. a 3.9er feature is out in the wild since then) * In Juno SR2: In the SR2 RC1 build we had 3.9.0.201212170307, in SR2 RC4 we have 3.9.0.201212170307. * The GEF feature is included in 4 packages: Automotive, Java EE, Modeling, and Reporting. (2) The version of a GEF bundle, e.g. org.eclipse.gef: * This bundle is included in all but one EPP package. * In Juno SR2: It comes as 3.9er version from the beginning, i.e. the first SR2 RC1 build contains 3.9.0.201212170307, the last SR2 RC4 build contains 3.9.0.201212170307. * (Looking back to Juno SR1: You were shipping 3.8.1.201208201742) Since there is a 3.9 feature shipped in the Juno SR1 repository, there's no way "back" to a 3.8 version of the feature (at least it's not a simple p2 way). Because the 3.9er version of the bundle had been included in all RC's of the Juno SR2 builds, I cannot see a reason why this bug could be a stop-ship bug (it's currently in RESOLVED INVALID state anyway). (In reply to comment #10) > Two observations first: > > (1) The GEF *feature*: > * (Looking back to Juno SR1: You were shipping 3.9.0.201208201742 - i.e. a > 3.9er feature is out in the wild since then) > * In Juno SR2: In the SR2 RC1 build we had 3.9.0.201212170307, in SR2 RC4 we > have 3.9.0.201212170307. > * The GEF feature is included in 4 packages: Automotive, Java EE, Modeling, > and Reporting. > Yes, that's what I would have expected. As soon as the first 3.9.0 milestone has been promoted, it has been picked instead of the intended 3.8.2 version. > (2) The version of a GEF bundle, e.g. org.eclipse.gef: > > * This bundle is included in all but one EPP package. > * In Juno SR2: It comes as 3.9er version from the beginning, i.e. the first > SR2 RC1 build contains 3.9.0.201212170307, the last SR2 RC4 build contains > 3.9.0.201212170307. > * (Looking back to Juno SR1: You were shipping 3.8.1.201208201742) Well, that's because I increased the feature versions directly after having branched of the 3.8 maintenance branch, while the bundle versions were not increased before having actually performed changes to the code base (which was after we shipped 3.8.1). > > Since there is a 3.9 feature shipped in the Juno SR1 repository, there's no > way "back" to a 3.8 version of the feature (at least it's not a simple p2 > way). > > Because the 3.9er version of the bundle had been included in all RC's of the > Juno SR2 builds, I cannot see a reason why this bug could be a stop-ship bug > (it's currently in RESOLVED INVALID state anyway). This is correct w.r.t. to the features. However, as in the case of Steve those clients that explicitly excluded 3.9 versions for the bundles will be impacted this time (in contrast to SR1, where only the feature versions, but not the bundle versions changed). From the fact that nobody has noticed (or at least reported) the wrongly shipped versions before yesterday, I assume that at least all simrel participants seem to be unaffected. Third party clients (as Steve) may still be impacted, but I assume they will probably run into deeper trouble if we now switch the features back to 3.8.2. If we intend to re-run the aggregator, the best would probably be to re-use the SR1 release versions (with the 3.9 features and the 3.8.1 bundles) instead of the intended 3.8.2 versions, so no clients will be impacted from the feature version downgrade. As I have already changed the gef.b3aggrcon to exclude the 3.9.0 versions, I would have to change them accordingly in such a scenario. As our project releases update site is still clean (the problem only affects the GA), - as David proposed - I tend to promote the intended 3.8.2 versions to it, independent on what we do with the aggregator.
> If we intend to re-run the aggregator, the best would probably be to re-use
> the SR1 release versions (with the 3.9 features and the 3.8.1 bundles)
> instead of the intended 3.8.2 versions, so no clients will be impacted from
> the feature version downgrade. As I have already changed the gef.b3aggrcon
> to exclude the 3.9.0 versions, I would have to change them accordingly in
> such a scenario.
Well, having thought deeper about this, I came to the conclusion that will finally remain for usage is not the SR1 but the SR2 release (and this will be there forever). So if we have the chance to re-run the aggregator, I would opt to include the intended SR2 bits into it (i.e. 3.8.2 features as now specified in the gef3.b3aggrcon).
So just to clarify, which GEF version should I consider being official for Juno SR2? 3.8.2 or 3.9.0? The official intended version is 3.8.2, i.e. 3.8.2.201301141834 to be exact. If we are respinning the SR2 simrel, I would propose to take it (and fix the problem we introduced in SR1 by already including wrong features (but still correct plug-ins). Alexander, You can not simply revert to 3.8 feature, since 3.9 is already in SR1. Its complicated, but since "higher" version is always prefer by p2, etc., things like EPP packages would simply pick up SR1 version, and if we tried it anyway, (and, say "constrained" EPP packages to get the right one), Then users would likely be told "sorry, you can't update because you already have a more recent version. In general ... you can never "go down" from released versions. You could revert back to your exact SR1 contribution so at least the bundle would be correct? I'm not sure there is a solution to "going down" in version numbers. (In reply to comment #15) > You can not simply revert to 3.8 feature, since 3.9 is already in SR1. I'd confirm this: Anyone using the 3.9 feature won't downgrade to a 3.8 feature, and the EPP packages would pick up the 3.9 from SR1. David, what did you guys use for your testing and builds on webtools during SR2? Did you use 3.9.0 or 3.8.2? Our team has been testing with 3.8.2. (In reply to comment #17) > David, what did you guys use for your testing and builds on webtools during > SR2? Did you use 3.9.0 or 3.8.2? > > Our team has been testing with 3.8.2. Carl told me earlier 3.8.2 bundle, but 3.9 bundle has been in EPP packages, which I know they've also been testing (and ... using, at least RC1!). Ok, I'm still confused about what I should be including in products that want to be based on Juno SR2 in my organization. Should I be supplying teams with GEF 3.8.2 or 3.9.0? And further, where can I find the official final versions in zip form (like GEF-runtime-3.8.2.zip and GEF-runtime-3.9.0.zip). I don't see them as Released here: http://eclipse.org/gef/downloads/index.php I only see Stable or Integration builds. Hi Steve, Alexander reported on cross-project-issues-dev that the GEF SR2 build could not be promoted as hudson was down because of a disk failure, a restore is being undertaken. Alexander also reported above that the GEF 3.8.2 build is supposed to be the Juno SR2. I am not sure that it matters for products that the Eclipse packages may have something different. (In reply to comment #20) > Hi Steve, > > Alexander reported on cross-project-issues-dev that the GEF SR2 build could > not be promoted as hudson was down because of a disk failure, a restore is > being undertaken. > > Alexander also reported above that the GEF 3.8.2 build is supposed to be the > Juno SR2. I am not sure that it matters for products that the Eclipse > packages may have something different. Exactly. As soon as the build server is properly restored (up to now there are still blocking issues with the file permissions) I will promote the artifacts of Hudson job gef-maintenance #212 (i.e. 3.8.2.201301141834) to our releases update site as the Juno SR2 release (including the zip drop files). Up to then you can consume this exact version from the milestones update site, the related zips are available as 3.8.2RC1. If the SR2 is respinned, there is a chance to also fix this in the simrel repo (by including the intended 3.8.2 versions there as well). Even if not, 3.8.2 is the intended release. Reopened, because if 3.9.0M5 is still to be included in the SR2 re-spin (following the discussions on the mailing list), we will have to revert my fix in the gef.b3aggrcon file (now, it would bundle the intended 3.8.2). This issue has been resolved. |