Re: [ide-dev] A "releases/latest" URL in the IDE to ease upgrades?

[Maarten Meijer <mjmeijer@xxxxxxxxxxxxxx>]

We should consider that the original question contains two different parts (as is usual with almost all user queries):

1) a statement of the desired outcome, i.c. easy migration to next major release (with all 3rd party plug-ins)

2) a proposal for the technical solution, i.c. changing the current p2 update mechanism

The discussion is about the second part, and we hear various pro’s and cons.

We already have automatic error reporting, this can probably be used for a sort of crowd sourced compatibility checking for 3rd party plugins possibly in combination with Eclipse market place.

As a safe guard for any problems and economic interests I think a major upgrade should result in a new parallel installation. 

When combined with automatic migration of 3rd party plugins, this is easy for the user.

Problematic plugins would be reported and removed after user consultation.

Such an install/migrate plugins solution can be integrated into Eclipse Oomph 

Kind regards,

Maarten Meijer
mjmeijer@xxxxxxxxxxxxxx

twitter: @eclipsophy
Committer Industrial Mylyn Connector
http://eclipselabs.org/p/industrial-mylyn/
Eclipse trainer/consultant
http://www.eclipsophy.com/

On 4 dec. 2015, at 08:16, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:

On 3 Dec 2015, at 17:34, Mickael Istria wrote:

On 12/03/2015 05:29 PM, Max Rydahl Andersen wrote:

Your expectation about good management of dependency versions we know from JBoss Tools and our attempt to get a build running for Eclipse next release just never works.It does for the base platform, but very rarely beyond that.

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.

Some could argue that the main reason Eclipse is alive is the wast amount of 3rd party plugins that are out there.

You could also argue it is one of the reasons it is not doing so well.

Thus no matter how you twitch this - Eclipse carries the burden of having an answer or be able to handle 3rd party plugins better.

I'm all for finding a better way of doing it but I do not believe the current state lets the best action be to enable major updates by default.

One issue I have with enabling these by default is that the user that would like to stay on i.e. Mars would constantly keep getting told there are major updates for Eclipse mixed in with micro updates to his plugins that he would like to get updates from.

I've suggested in the past that we clean up the default release train (remove any default additions of project update sites - sometime enabled, sometimes disabled) so we actually from Eclipse side has a clean setup. Would get updated for each .1 and .2 release. Call it 'minor-site'

Then we should allow for enabling a site that includes project update sites (this is what Doug would like for CDT) so these can get updated when content are available vs when the release train goes out. No known api breakage, just micro's. Let's call that the 'micro-site'

We could then also add a 'major-site', one that contains stuff that starts breaking things. To begin with make it release-train content but could argue other projects could add things.

Find a way to make this visible/managable to the user without making it default to constantly update would be interesting.

/max
http://about.me/maxandersen

_______________________________________________
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