I think Jonah sums up what I also think quite nicely, so +1 to that. -- Torkild Ulvøy Resheim Consultant / Eclipse Committer / Senior Software Developer Itema AS - http://itema.noOn 3 December 2015 at 15:06, Doug Schaefer <dschaefer@xxxxxxx> wrote:For major releases, though, I’m not sure it should be automatic. But it
definitely should be easier. It wouldn’t be hard to add a feature that check
for the availability of the next major release and offers to set up the p2
repos to get it. Ubuntu works this way and I felt that was a good
experience.
Earlier in this conversation Doug mentioned Ubuntu, I think the Ubuntumodel is an excellent model to follow in this case. I agree thatauto-update should not do major version upgrade, but I think usersshould be notified that there is a new major version.Once a new major version is available, the user should be given theopportunity to trial the upgrade, i.e. run the p2 installer with thenew update sites, but stop short of doing the install. If that passesand satisfies the user, the update sites configured should be updatedto the new version as part of the upgrade.In summary +1 for doing auto-updates and +1 for the Ubuntu model.~~~Jonah GrahamKichwa Coders Ltd.www.kichwacoders.comOn 4 December 2015 at 16:08, Konstantin Komissarchik<konstantin.komissarchik@xxxxxxxxxx> wrote:It is a search that stops after some iterations so it is not guaranteed it
will find the right solution.
And what happens in that case? It simply shows the conflict and apologizes
about not being
able to make an installation proposal? It doesn't affect current
installation so nothing is broken?
I believe it's an acceptable behavior to present to user. The error they
get would be enough
to let them take the action they prefer.
No, not acceptable. If a Neon.1 user cannot update to Neon.2 due
interference of Neon+1 in the update search space, then we’ve made things
worse for many users.
Thus requires experimentation to see how it behaves in "open battle" with
the whole ecosystem :)
Experimenting with this scenario would be good, but only a negative result
(discovering a case where p2 doesn’t offer a correct update) would be of
use. It would be good to hear a statement from the p2 team regarding the
behavior in this scenario. If the statement isn’t full confidence in p2’s
ability to find the correct solution in this scenario, then I don’t think we
can proceed with the simple solution of adding the “latest” repository to
the list of known repositories.
That doesn’t rule out alternative solutions. We currently have a single
group of update sites to search for updates. We could improve p2’s chances
of finding a solution by having several groups to search through instead of
a single large group. For instance, Group 1 could contain Neon repo and
Neon-specific repositories added by others, while Group 2 contains the
“latest” simrel repository with corresponding third-party repositories. When
searching for updates, p2 could try Group 2, if failed to find a solution,
try Group 1, etc. This would give us a way to constrain p2’s search space,
but does require the tooling to be improved first.
- Konstantin
From: Mickael Istria
Sent: Friday, December 4, 2015 7:02 AM
To: ide-dev@xxxxxxxxxxx
Subject: Re: [ide-dev] A "releases/latest" URL in the IDE to ease upgrades?
On 12/04/2015 02:06 PM, Max Rydahl Andersen wrote:
It is a search that stops after some iterations so it is not guaranteed it
will find the right solution.
And what happens in that case? It simply shows the conflict and apologizes
about not being able to make an installation proposal? It doesn't affect
current installation so nothing is broken?
I believe it's an acceptable behavior to present to user. The error they get
would be enough to let them take the action they prefer.
Thus requires experimentation to see how it behaves in "open battle" with
the whole ecosystem :)
Right, I add to my todo-list to try tricky scenarios and I'll report back.
But I have big hopes about the remediation, I only had good suggestions from
it so far, and never got a "broken" installation.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets
_______________________________________________
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 listide-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/ide-dev
|
