| 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. Thanks, - Konstantin
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. Doug. 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. > >Brian. > >[1] https://wiki.eclipse.org/FAQ_Revert_an_Update_or_Installation_with_p2 >[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 >ide-dev@xxxxxxxxxxx >To change your delivery options, retrieve your password, or unsubscribe >from this list, visit >https://dev.eclipse.org/mailman/listinfo/ide-dev _______________________________________________ ide-dev mailing list ide-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ide-dev |