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.