Separate updater code from core in releases

[PVince81]

Provide a separate channel for only the updater code. This way there is only ever a single updater codebase that needs to update itself.

This would make it easier for testing and fixing update issues by telling people to update the updater to the latest version.

@VicDeo @DeepDiver1975 @davitol

[PVince81]

cc @SergioBertolinSG

[PVince81]

@jvillafanez I think you had big ideas for this but can't remember where you posted them

[DeepDiver1975]

This was the concept of the current implementation. What is missing?
I fail to see the reason for this issue.

[VicDeo]

@DeepDiver1975 I guess the point here is separate code delivering

[PVince81]

Added missing part "in releases".

What I mean is providing a way for the updater to update itself independently from core.

So if you're on OC 9.0.3 and we have an important fix to make updating work, then the updater would first update itself to the latest version and then do the core update.

[PVince81]

This also means that we only maintain one updater version, the latest one, instead of maintaining multiple updater versions, one for each core branch.

[VicDeo]

@PVince81 I would offer to do it in a silent, unconditional and single-file manner.

[jvillafanez]

Well, better rewrite them again here 😄

Let's simplify the updater:

• Do we need different channels? I don't think so. The updater should just provide a couple of versions: if the current version is 9.0.2, the updater should provide just 9.0.x (latest 9.0 available) and 9.1.x (lates 9.1 available). Channels add unneeded complexity from my point of view.
• No self-updating, at least for now. This is more complex than it looks. It's fine to consider this and plan for this, we should live without it. Just a message saying "you have a new updater version in this url, please download it" it's more than enough. It's user's responsability to download the new code and use it.
• Updater code should be completely isolated and independent from core. It should be as dummy as possible. It should be possible to develop the updater using any language, and the only reason to use PHP is because we might need to read the ownCloud configuration file.
• The updater must NOT be an ownCloud app. We could integrate ownCloud and the updater later, as an external system.
• The updater must be delivered outside of the ownCloud package (this includes tarball).

There is still the open issue of "ownCloud versions discovery". Using an "updater server" is way to complex and make testing difficult: we need to start a server, patch the server code with the something to provide the new ownCloud version, connect the updater to the patched server....
Using just a plain json file is more than enough from my point of view. You can just tell the updater to use this specific json file, or pick it from an url.

As an additional note, the updater should be able to update any ownCloud installation. If I have several ownCloud in my computer, the same updater should be able to update all of them, not all at once but the ones I want. I don't want to download one updater per ownCloud installation.

I guess this sums up my opinion.

[DeepDiver1975]

This is where phar can be of interest- at least for cli

[VicDeo]

There is still the open issue of "ownCloud versions discovery". Using an "updater server" is way to complex and make testing difficult: we need to start a server, patch the server code with the something to provide the new ownCloud version, connect the updater to the patched server....

There is no need to deploy the whole update server

config/config.php
'updater.server.url' => 'http://someserver/fakeresponse.xml',

fakeresponse.xml:

<owncloud>
<version>100.0.0.0</version>
<versionstring>ownCloud daily</versionstring>
<url>
https://download.owncloud.org/community/owncloud-daily-stable9.1.zip
</url>
<web>
https://doc.owncloud.org/server/9.0/admin_manual/maintenance/upgrade.html
</web>
</owncloud>

or

<owncloud>
<version>100.0.0.0</version>
<versionstring>ownCloud daily</versionstring>
<url>
https://myserver.tld/my-own-stable9.1-patched-very-hard.zip
</url>
<web>
https://doc.owncloud.org/server/9.0/admin_manual/maintenance/upgrade.html
</web>
</owncloud>

[VicDeo]

Any pastebin service can be a custom update server:

http://pastebin.com/raw/R6vgT6SJ

[jvillafanez]

We should consider removing the update server from this. Just provide a file in xml, json or whatever format with the whole list of versions and let the updater choose the best options for the server it wants to update.

Removing the update server leads to a simpler architecture and make things easier to test from my point of view.

Note that it's MANDATORY to automate this. Any change that makes the updater easier to automate should be really welcomed, because this will only get bigger and bigger.