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?

On Fri, Dec 4, 2015 at 1:12 PM, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:
On 4 Dec 2015, at 12:24, Bruno Medeiros wrote:

"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?"

The update mechanism in Eclipse will only update automatically if it can
update all existing features successfully. So if it tries to upgrade to
Neon, but there is a feature that requires Mars only, it will fail the
update, and instead present a dialog with some possible choices (one choice
being uninstalling the feature that requires Mars-only, so that update to
Neon can proceed). But it will never uninstall features automatically, or
proceed with an update that breaks such features.

That's why I think it's ok to have Eclipse try to update across major
Eclipse versions. If there is a 3rd party plugin that is only supposed to
work on Eclipse 4.3 only, then that should be specified if the feature
where the plugin is bundled with, so that Eclipse isn't broken when a major
update is attempted.

 This is problematic.

i.e. take JBoss Tools, we deliberately does not set an upper limit if we can avoid
it so we can actually test if the install will work on the "yet-to-be-known" major next
version of Eclipse - and we thus rely rather heavily on default behaviour does not add in Neon
to Mars update sites; but users who know what they are doing can actually try to experiment
and add Neon and report to us if there are issues.

If this change happens I could see we would have to limit the version of Eclipse our plugins
could be installed on - and thus making it even longer before we could provide a release for the next major.

I don't have a good answer to this and I know it is part of the problem itself - but just wanted
to highlight it is not trivial ;)

If you know of a way to solve the above without actually having to release a complete new set of binaries
just to test on next major that would be great to hea.


Hum, good point, and now that you mention it, I've been on a similar situation. The IDE projects I develop (Melnorme IDEs), they depend on CDT, but use some internal CDT API  (especially the earlier Melnorme versions), and so, it was quite possible that an upgrade from say CDT 8.6 to 8.7 would break the Melnorme IDEs. Because of that, initially, the IDE features were coded to depend strictly on just CDT 8.6.x. But it turned out most of the time it would work fine with the next CDT minor version, but users couldn't update because the dependency was hardcoded in the feature.xml. A new release was required.
So that was changed, to allow installing Melnorme with any CDT 8.x.x release (any major Eclipse release then). Each release of our IDE project was then annotated with a recommended CDT version, which was the last one the project was actually tested on, and was expected to work. I'm guessing JBoss Tools is in similar situation?

That said, I'd still like a way for users to be able to update to a new Eclipse major version, without having to manually add an update site. Perhaps Jonah's solution would be appropriate then?

--

Back to the top