|Re: [ide-dev] A "releases/latest" URL in the IDE to ease upgrades?|
On 03.12.2015 17:34, Mickael Istria 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.
I agree completely. But breaking users' installations, or presenting them with a complex remediation "solution" might not be the most helpful way ;) Also keep in mind that when an upgrade causes problems due to 3rd-party plugins messing it up, this probably won't fall back on the 3rd-party plugin, but on Eclipse, which is after all suggesting/performing the upgrade.
Just doing a normal update on a "latest" repository isn't the way I can see this work. Even now, with just the current release train repo, I regularly run into conflict situations where remediation runs for hours - and I'm not talking about figurative hours here... Also, those typical conflict messages P2 spits out are not really parseable by many users (I am regularly called to one of my colleagues to help them understand them)
An additional problem with 3rd-party plugins (or possibly even Eclipse ones outside the release train) is that with a nice "latest" repository for the IDE, I'd still probably need to update some 3rd-party plugin repos for the new release as well.
However, I think if the upgrade is presented properly and maybe handled a little differently than a minor update, it would even be okay for the user if it breaks some 3rd-party stuff - especially when upgrading becomes much easier.
What I could see working well is 1) As already suggested, prompt explicitly about the major update 2) Calculate an upgrade scenario that upgrades (just) the running product 3) Try to find a solution for all other installed plugins3.a) If no matching version for a plugin is found, ask the user to add/change repositories, then retry 3.b) Disable/Uninstall incompatible plugins (It would be great if we could just disable them and check later if a compatible update might be available. But I'm not sure if P2 can do that right now)
This is similar to how Mozilla runs its updates for Firefox and Thunderbird and not too different from what Chrome does either.
Back to the top