Community
Participate
Working Groups
I20111115 1) Install a 3.8 build 2) Open it, and invoke Help > Check for Updates. You will be prompted to upgrade to 4.2. This happens because the Juno repository is enabled by default, which references the platform 4.2 repository. I'm curious what others think, but this feels wrong. If someone downloaded 3.8 it's probably because they specifically didn't want 4.2. I upgraded by 3.8 I-build to 4.2 this week by accident because of this (admittedly I should have looked closer about what the search for updates was recommending to me). The only mechanism I can think of to avoid this is to exclude the juno repository from the 3.8 SDK by default. We could also tweak the 4.2 repository metadata to disallow upgrading from 3.8 to 4.2, but that seems heavy-handed given that the upgrade actually works fine (it just isn't likely what you are looking for).
I don't expect that update as some external bundles might not work well on 4.2, but can work well on 3.8. Installing 4.2 by mistake can end up with a broken workspace for users.
We don't have major version upgrades very often. I *have* seen this in other applications, where the user usually receives a special message (i.e. different than the normal upgrade-to-a-new-minor-version message) indicating a major upgrade is available -- somewhat like the "distro upgrade" versus normal upgrades for linux installs. Is it possible to do something like this?
I like McQ's idea but suspect it might be difficult to do unless we distinguish between regular IUs and these somehow.
For my 2 cents worth of advice, I'd definitely not have juno on 3.8 sdk. I assume you'll have a separate eclipse/updates/3.8 repo, so that'd be only one, I'd suggest. As for having another enhancement, that allowed "dist-upgrade" (or similar) that'd be great for cases where users themselves added Juno repo to 3.8 ... just give a little extra "protect users from themselves" ... but, wouldn't want that to be the primary fix. And, yes, I agree, we should not _prevent_ upgrading from 3.8 to 4.2 as there could be some situations where that would be appropriate and desired ... but, not the norm. HTH
This is similar to the forking problem. How do I have two implementations of the same thing and don't want them to mix and usually the version numbers would cause one to upgrade the other. The only real solution I can think of is to keep the p2 repos separate and as John suggests, don't put the Juno repo in the 3.8 SDK. If users later wish to upgrade to 4.x, then the can add the Juno repo and do the upgrade. Messy, but that usually means we missed something in the design.
(In reply to comment #0) > The only mechanism I can think of to avoid this is to exclude the juno > repository from the 3.8 SDK by default. We could also tweak the 4.2 repository > metadata to disallow upgrading from 3.8 to 4.2, but that seems heavy-handed > given that the upgrade actually works fine (it just isn't likely what you are > looking for). +1. Maybe we can put the 3.8 platform repo in by default (if such a repo exists).
By default auto-upgrading from 3.8 to 4.2 should be disallowed unless we find a way to warn the user as currently, upgrading from 3.8 to 4.2 destroys all perspectives (bug 363600).
Because the Eclipse SDK is available from Juno this can catch out anybody that gets 3.8, installs something from Juno (Xtext, EMF, etc) and then tries to update to get Juno SR1. PW
Created attachment 207146 [details] patch
Fixed. I would have fixed this yesterday but it looks my email wasn't working and I didn't receive any bugzilla mail yesterday afternoon.
Kim, there are a couple of suggestions in the discussions here. Which fix did you put in?
I just removed the Juno repo from being listed as a repo in the 3.8 install.
I think there is a deeper problem here. As mentioned above we need to consider having a 3.8 repo. Consider the following use case: - user downloads 3.8 - user wants to install something - no repos exist so they add Juno - now they are in the same position as if we shipped the repo link in the zip We can't prevent them from adding the Juno repo, but we should give them an easy alternative (e.g. 3.8 repo) which won't accidentally get them to update from 3.8 to 4.2.
Re-opening until we figure out how users will install new things into 3.8.
(In reply to comment #13) > We can't prevent them from adding the Juno repo, but we should give them an > easy alternative (e.g. 3.8 repo) which won't accidentally get them to update > from 3.8 to 4.2. I agree it'd be nice to give some "extra" confirmation and warning a major upgrade can break their system ... but ... I would like to urge caution on the idea of having a 3.8 based repo "for everything". For one, it'd be easy for that to increase work for many people ... including me :) ... but, more important, I think 4.2 is expected to be the vast majority of install bases, and 3.8 based installs are anticipated for relatively few adopters that can not get "lined up" in time for Juno. I would not want to give the impression that 3.8 and 4.2 were "50/50" and equally valid choices ... the choice should be 4.2 unless some adopter knows they need 3.8. Technically speaking, we do not even know yet, that everyone in Juno release train is willing to support 3.8 based installs ... I think most/majority will in some form ... but ... that is not technically required to be in Juno. Of course, if we really need some 3.8 repo then we really need it ... I just wanted to urge caution when thinking along those lines of a having a "3.8 repo". I'd hope some extra caution/warning/confirmation and/or preference choices would suffice?
Doesn't p2 meta-data support specifying which IUs should be updated? I don't know if this works but if we limited the version range in the content.jar to something like this maybe p2 wouldn't prompt users to update a 3.8 SDK? <unit id='org.eclipse.sdk.ide' version='4.2.0.I20110805-1200'> <update id='org.eclipse.sdk.ide' range='[4.0.0,4.2.0)' severity='0'/>
(In reply to comment #16) > Doesn't p2 meta-data support specifying which IUs should be updated? I don't > know if this works but if we limited the version range in the content.jar to > something like this maybe p2 wouldn't prompt users to update a 3.8 SDK? > > <unit id='org.eclipse.sdk.ide' version='4.2.0.I20110805-1200'> > <update id='org.eclipse.sdk.ide' range='[4.0.0,4.2.0)' severity='0'/> Yes it does. That is what I meant by "tweak the repository metadata" in comment #0. I wanted to confirm that this just influences the automatic update checker and doesn't actually prevent someone from doing the upgrade if they manually select it. If it does this, I think it is a good fit. I definitely don't like the idea of having two juno repositories (one with the link to 4.2 and one with the link to 3.8). This will just be confusing for the user community.
I downloaded the content.xml for a 4.2 build and tweaked the update descriptor to be [4.0, 4.3) as indicated in comment 16. Doing a Check for Updates in a 3.8 build said there were no updates. Doing an Install New Software and picking the 4.2 version allowed me to continue with the installation. This sounds like the behaviour we want for Juno. I'll work on a p2.inf file for the SDK and Platform IUs. Are there any others?
DJ see the patch, platform.sdk, platform, SDK, p2.agent need them.
Created attachment 207186 [details] Modified p2.inf files Here is a patch which modifies the p2.inf files for the SDK, Platform, and Platform SDK build configs. It is based on the R4_HEAD branch in CVS. (I am assuming the eclipsebuilder project hasn't been converted to git yet) I'm not sure I understand the p2.admin reference in the previous patch because it shows removal of the Juno update site from the p2 Admin but in the p2.inf for the p2.admin in the R4_HEAD branch, it still has the Helios update sites listed. I'm not sure why there is the discrepancy. Either way, I'm not sure we need the modified entries in the p2.admin product. I don't believe it is as big of a deal if the user updates to a 4.x based tool. We can add it if anyone feels strongly about it.
The discrepancy is because I was looking at the HEAD version which is used for 3.8 builds.
I have a small concern with this approach, are we limiting those who build applications on top of our platform? This seems like a Eclipse End-User problem -- we don't want users of the Eclipse IDE (or EPP Packages) to get updated to 4.x if they picked a 3.8 build. However, this approach (the p2.inf file) will limit all consumers of the Eclipse platform from shipping 4.x updates to a 3.x application. Maybe I'm missing something here.
(In reply to comment #22) > I have a small concern with this approach, are we limiting those who build > applications on top of our platform? This seems like a Eclipse End-User > problem -- we don't want users of the Eclipse IDE (or EPP Packages) to get > updated to 4.x if they picked a 3.8 build. However, this approach (the p2.inf > file) will limit all consumers of the Eclipse platform from shipping 4.x > updates to a 3.x application. I don't think so... this is a product-level configuration setting. DJ's patch is setting the update descriptor for the Eclipse SDK product, Eclipse Platform product, etc. If someone builds a higher level product that includes platform 3.8 feature they could still allow that to be upgraded to a newer version of *their* product that includes platform 4.2 feature. p2 looks for update descriptors on the root IUs only.. for any features below those roots we don't even look at the update descriptors.
(In reply to comment #23) > I don't think so... this is a product-level configuration setting. DJ's patch > is setting the update descriptor for the Eclipse SDK product, Eclipse Platform > product, etc. If someone builds a higher level product that includes platform > 3.8 feature they could still allow that to be upgraded to a newer version of > *their* product that includes platform 4.2 feature. p2 looks for update > descriptors on the root IUs only.. for any features below those roots we don't > even look at the update descriptors. That's very well explained (and very accurate). Thanks John. So really it will depend on 'how' the customers product is assembled. If someone creates their own products, and re-uses an Eclipse.org platform/SDK feature then they are free to set their own updates and this change won't get in the way. However, if someone takes an Eclipse platform (or SDK) and uses the director to assemble their components on top, then they won't be able to update (from 3.x to 4.3). Interestingly, if they first point to a 4.2 repo, the update will succeed (since our 4.2 repos didn't have these update descriptors). I'm not opposed to this, I just want to understand the limitations of this solution so we don't get bitten down the road.
(In reply to comment #24) > So really it will depend on 'how' the customers product is assembled. If > someone creates their own products, and re-uses an Eclipse.org platform/SDK > feature then they are free to set their own updates and this change won't get > in the way. However, if someone takes an Eclipse platform (or SDK) and uses the > director to assemble their components on top, then they won't be able to update > (from 3.x to 4.3). Yes, except "won't be able to update" is a bit strong. If they do Help > Install New Software and select platform or SDK version 4.2, they will still be able to install it. However, if they do Help > Search for Updates, it won't find it. Some people have made the suggestion here that we should still offer the upgrade, but give a very clear warning about what is going on. ("Warning: You are upgrading to a major new version"). I have a few problems with this... 1) We don't have any mechanism to do this today. 2) User will repeatedly be offered to do this upgrade every time they search for updates, and 3) I'm not convinced users carefully read all the text when upgrading and might not understand what they are getting into. > Interestingly, if they first point to a 4.2 repo, the > update will succeed (since our 4.2 repos didn't have these update descriptors). I don't understand what you mean here. DJ's patch is to change the update descriptors for the 4.2 repository. Did you mean 4.1?
(In reply to comment #25) > Yes, except "won't be able to update" is a bit strong. If they do Help > > Install New Software and select platform or SDK version 4.2, they will still be > able to install it. However, if they do Help > Search for Updates, it won't > find it. We should double check this. I agree they will find it, but it won't be an 'update'. Under the covers, we may try to install SDK 4.2 while keeping SDK 3.8 (i.e. 3.8 won't be uninstalled). > > I don't understand what you mean here. DJ's patch is to change the update > descriptors for the 4.2 repository. Did you mean 4.1? Sorry, you're right. 4.1. I'm a year ahead of myself.
It was brought up on the Equinox call today that the current behaviour is relying on a bug in p2. I've opened bug 364422 for us to discuss this. Note in this bug we have been talking about going from 3.8 to 4.2 but in reality we need to consider the fact that consumers in the field are running 3.7.2 and will be prompted to update to 4.2. (read: we may not be able to put a fix into client-side code)
(In reply to comment #27) > Note in this bug we have been talking about going from 3.8 to 4.2 but in > reality we need to consider the fact that consumers in the field are running > 3.7.2 and will be prompted to update to 4.2. (read: we may not be able to put a > fix into client-side code) And to further DJ's point, what is the expected behaviour when you have 3.7.x installed (and you search for an update)? Would we like them to get 4.2 or 3.8 (of course they will need to add the appropriate repository first)? The proposed solution (tweaking the update descriptors) won't allow updates from 3.7.x to 4.2 either. In the past, we have never advertised these year-to-year updates, but they have worked. I'm not sure how many people use this as their means of updating Eclipse.
(In reply to comment #28) > (In reply to comment #27) > ... In the past, we have never advertised these year-to-year > updates, but they have worked. I'm not sure how many people use this as their > means of updating Eclipse. By saying "they have worked" ... I think you mean that update path works for Platform or Eclipse SDK (and maybe some others) ... but, the concern in previous years has been that it might not always work for all Eclipse projects or products built on them, and no one was ready to sign up for extra testing to support that ... so, that's why it was never "advertised". I just didn't want to leave the impression updating from 3.7 stack to a 4.2 stack would be "guaranteed" to work ... it might work just fine, but it might not, depending on the specifics of what else the user had installed (and if all those other things specified their constraints and version pre-reqs correctly).
I have done the following: - Reverted Kim's original patch to remove Juno repositories from 3.8 products. Without this repository it is difficult for end users to install Juno-related content from other projects - Released DJ's patch to R4_HEAD and R4_2_primary streams. Kim does org.eclipse.releng.eclipsebuilder need to be tagged, or does the bootstrap pick it up directly from the branch?
eclipsebuilder needs to be tagged, I did this yesterday so this should be in builds >= 20120124-2000
