Bugzilla – Full Text Bug Listing
| Summary: | core resources bad version in 3.6 composite repo | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Paul Webster <pwebster> |
| Component: | Releng | Assignee: | Kim Moir <kim.moir> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | aniefer, daniel_megert, david_williams, john.arthorne, kim.moir, Mike_Wilson, remy.suen, serge, Szymon.Brandys |
| Version: | 3.6.1 | ||
| Target Milestone: | 3.6.1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Paul Webster
There was a change committed between 3.6 and 3.6.1. It was Bug 318162. I missed that the manifest was not updated and it seems that the releng tests did not pick it up. While I know we can't really fix 3.6.1 itself, is there something we can do here? i.e. if we increment core.resources to 3.6.2 in SR2 then (in theory) someone could fix the version of core resources in SR1 for their distributions. If we do nothing, that makes it hard to talk about SR1 (it can't be moved up, post-fixed, etc). Balance that against the fact we're contributing RC4 build to Helios SR2 train ... today. PW (In reply to comment #1) > There was a change committed between 3.6 and 3.6.1. It was Bug 318162. I missed > that the manifest was not updated and it seems that the releng tests did not > pick it up. I think we currently don't have a test to cover that case. (In reply to comment #2) I'm not sure we'll succeed in doing a rebuild today so that we can successfully contribute it EOD. If we contribute later, I think we need to inform the cross-project list. John, do you know the details? Just to summarize: the problem does *not* affect 3.6.2 as the version (service segment) has increased: our 3.6.2 RC4 candidate has:
org.eclipse.core.resources_3.6.1.R36x_v20110131-1630.jar
==> The only thing we might do (if possible) is fixing the 3.6.1/SR1 repository (if we indeed have separate repository for SR1 and SR2, which I don't know for sure). This can be done by pushing the 3.6.2 bundle into it (risky) or by rebuilding 3.6.1 with a tag the is bigger than "v20100526-0737". If we don't have a separate SR1 repository then everything will be fixed once 3.6.2 is published.
FYI: Filed bug 337193 requesting a releng test case so that we discover such issues earlier in the future.
I don't know that we are going to proceed with a fix for this bug given that 3.6.1 has been released. Yes, the 3.6.0, 3.6.1 and 3.6.2 repositories are all separate child repositories. However, you can't just insert a 3.6.2 core.resources bundle into the 3.6.1 child repo because this would mean that the feature versions would need to be incremented to accommodate this change. I'm going to close this bug given that bug 337193 has been opened to address the comparator, and this issue has been fixed in the 3.6.2 stream. (In reply to comment #5) > ... > Yes, the 3.6.0, 3.6.1 and 3.6.2 repositories are all > separate child repositories. > ... Just to clarify, a little, the common repository, /releases/helios does treat and use these as separate child repositories, but only for the artifact repositories. (That's to avoid duplicate storage). The content repositories (metadata) is always "merged" to have just one. This is mostly so the 'categories' in the common repo can be different from what they are in the separate project level repositories. So, even if 'platform' created a new child repo, the common repo would have to be "rebuilt" to get the content/metadata correct. And ... if it very very hard to do a rebuild of the common repository, simply because history has shown not all projects are good about maintaining "rebuild-able repositories". In the past, when we had to do this, we basically had to tweak all the contribution files, to point back to the common repo, except for those repositories we knew were changing. Doable, but not easy, and not especially safe, in the sense there's no tests to run, etc. to ensure things end up as we expected. Just adding to the knowledge base ... :) |