Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] A "releases/latest" URL in the IDE to ease upgrades?

Is p2 smart enough today to try less aggressive update option if a mix of update possibilities is found?


Consider an installation that has Neon.1 installed after Neon.2 and Neon+1 are out. The installation also has a plugin that will work with Neon.2, but not with Neon+1.


When user does check for updates, Neon.2 and Neon+1 are two update possibility. Will p2 go down the most aggressive path that will require remediation (removing third-party plugin that the user may not be ready to part with) or will it try a less aggressive path that will resolve cleanly?


I am generally in favor of exploring this further and I am ok with saying that third-party plugin providers have to change how they distribute accordingly so all of their updates are found too, but we need to make sure that we aren’t making things worse for users.




- Konstantin



From: Doug Schaefer
Sent: Thursday, December 3, 2015 9:04 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] A "releases/latest" URL in the IDE to ease upgrades?



I¹m with Mickael here. If we never start, we will never change the culture

that has led us here. I¹m fine if 3rd party plug-ins break things. Users

can always reinstall and rebuild their workspaces from scratch, which

unfortunately is something they¹ve become used to anyway. But let¹s find

out how bad things really are before throwing away an opportunity to make

things better.




On 2015-12-03, 11:52 AM, "ide-dev-bounces@xxxxxxxxxxx on behalf of Brian

de Alwis" <ide-dev-bounces@xxxxxxxxxxx on behalf of

briandealwis@xxxxxxxxx> wrote:


>On 3-Dec-2015, at 11:34 AM, Mickael Istria <mistria@xxxxxxxxxx> wrote:

>> At some point, I believe the IDE has to "lead" the ecosystem, by being

>>more helpful to its users, including allowing updating from Mars to

>>Neon, and that 3rd-party in the ecosystem have to adapt accordingly or

>>die. Eclipse IDE doesn't have to handle all the pain created by 3rd

>>party plugins and should be really focusing on its users more than on

>>all the possible ways for 3rd-party plugins to mess it up.


>Except we have no way to discover which of those 3rd party plugins do

>mess up.  And you can be sure that at least 30% of the users will have

>one of those plugins installed :-(


>I¹d definitely support alerting of major upgrades if we had a better

>rollback story [1], such as a button on the Switch Workspaces button, or

>being able to hold down Ctrl+Alt on start [2].  But it needs to be rock

>solid.  I¹ve had mixed success in rolling back changes using the About >

>Installation dialog: some have failed as the old features and bundles

>can¹t be found (deleted from the bundle pool?) and couldn¹t be found at

>any of my configured update sites.





>[2] But I¹ve not been able to figure a way to query SWT as to which

>modifier keys are currently held


>ide-dev mailing list


>To change your delivery options, retrieve your password, or unsubscribe

>from this list, visit




ide-dev mailing list


To change your delivery options, retrieve your password, or unsubscribe from this list, visit



Back to the top