-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make CLI upgrade the default to avoid timeouts, web UI upgrade only for shared hosters #17091
Comments
We need to offer both options. A ver prominent hint how it is done via the cli and optionally and only for smaller instances the option via the web interface. |
Ref #14229 |
AFAIK, a standard Wordpress config doesn't encrypt tens of GBs @pvince, in your proposal, the web updater should be the preferred option when updating apps, but for that to happen, it first needs to learn about the difference between a core and an app update (#16272) |
No. In my proposal the CLI update should be the preferred option. The update page (see disambiguation above) should only be there for people who have no CLI access (ex: shared hosters) and that could be achieved by having that page being a part of the updater app (see disambiguation above). The update process (the one from the update page) can know about core and app update, it just doesn't show the correct message. |
Actually, @PVince81's proposal will help massively in reducing the ambiguity surrounding an 'update' or an 'upgrade', if we move the web upgrader to the Updater app. As long as the Updater app is installed by default on all releases (I think it is?) then it's 👍 from me. |
I disagree with a cli only approach for app updates, unless you disable the app store as well.
That's just nonsense from a UX point of view. |
this is indeed true - so we have to differentiate between core and app updates? |
I think we should. It's much safer to upgrade oC from the cli and since there are plans to log everything when performing an upgrade, an admin will have quick access to the logs and will be able to fix things quickly. For apps, a web upgrade is perfectly fine, except if the encryption app wants to make massive changes all the sudden, but that has always been introduced with oC upgrades. |
we should have a detailed discussion about this - maybe there is something to do within the cycle of 8.2 |
It's the design goal of ownCloud to provide a solution that can be hosted on a private webspace. We should be able to deliver that. |
The problem is more serious that that indicated at the beginning of this thread. The problem is that everybody on the internet is given the opportunity to start the upgrade with the button. This means that when the administrator upgrades owncloud, he cannot know for sure when the updated will be triggered. This is a bad and potentially dangerous situation. |
@karlitschek @DeepDiver1975 @PVince81 I assume this is something for 9.0? Do we have another issue with a lowdown of what we discussed at the conf about the updater process? |
@jancborchardt An implementation is available over at #18782 btw |
upgrade is one big topic for 9.0 - setting milestone accordingly |
Not sure if we want to do this right now, could do later, or drop the topic. Thoughts ? @DeepDiver1975 @butonic @pmaier1 @felixboehm |
probably just a matter of 1md to add an option. |
Well, this does not block anything since you can always use OCC to upgrade. If app upgrades can still be done via web (#17091 (comment)) making this default would improve the behavior and guide admins so it should definitely not be abandoned. Moreover I'd regard it as bad practice that anyone can trigger the update via the WebUI. Should be changed! |
Moving to backlog for now, unless someone is willing to contribute a PR for this |
This issue has been automatically closed. |
Disambiguation:
The problem:
Goal:
Proposal:
The text was updated successfully, but these errors were encountered: