Updating with the masterserver

OpenClonk will have an automatic update system like Clonk Rage. However, the update logic will not be in the engine anymore. The masterserver acts as the facilitator between the update packages on the server and the engine. Basically, the process looks like this: The engine asks for an update by sending his version information to the masterserver. The masterserver responds with the new version information and path to the right update package for the engine. The engine will then download that update package and apply it.


This proposal is intentionally kept as simple as possible: The different pieces of code only need to communicate one version number to each other, apart from the build server uploading update packages and full packages. This is a little wasteful of disc space and bandwidth, because one update package for every old supported version needs to be uploaded and stored. If this is a problem, the build server could create one cumulative update package and copy that locally on the download server. Or we could pass around update URLs from the build script to the masterserver to the engine, so that different engine versions can download the same update URL. Newton and ck already wrote a spec for that that can be used if necessary, but maybe this simpler version suffices.

Masterserver interface to the Engine

Additionally to the list of running games, more information will be shown by the masterserver. This includes the most recent engine version and the message of the day.

Version=<Most recent engine version>
MOTD=<A message of the day>

If the engine specifies an additional parameter called "action" with the value "version", only the above [Info]-section will be displayed, not the list of running games. Example:


How the engine constructs the update url

If the version information from the masterserver indicate that it's time to update, the engine downloads a url like this:

http://openclonk.org/builds/updates/from_[platform]_[engine's old version].c4u

Platform will be any of win, linux or mac. (The two different architectures 32bit and 64bit are both included in the update package.) The version is for example 5_1_2_3.

Interface to the build scripts

The build scripts upload the update packages to the download server. For every supported old version, one update package is uploaded, replacing an old one if necessary.

Afterwards, they notify the masterserver about the new version number. (FIXME: How exactly? GET http://boom.openclonk.org/new_version?version=

Download page

The build script also uploads an html fragment to the download server containing links to the full installation packages that gets included on the download page. Example:

<ul><li><a href=http://openclonk.org/downloads/openclonk_[version].exe>Windows</a></li>
<li><a href=http://openclonk.org/downloads/openclonk_[version].tar.bz2>Linux</a></li>
<li><a href=http://openclonk.org/downloads/openclonk_[version].zip>Macosx</a></li></ul>

(FIXME: Or do we simply replace the full packages, using a versionless filename?)

Versioning and updates

The versioning will be 5.A.B.C, whereas...

A = major release (Back to the Rocks, etc.)
B = bugfix release / minor changes
C = build number of the engine

The build scripts will generate c4u update packages that can be applied to the last X released versions, independent of which numbers in the version string did change. (While X will probably a number around 10-20. But this number can easily be changed by the build script with this design.) For any versions that are not covered by this update anymore, old update packages will be served. (There is a feature request to support downloading a full release and replace the current installation without using the update mechanism, but that is not written yet.) The exact logic when to and for which versions to supply an update package is be decided by the build script server.

RPMs, DEBs etc. are not covered by this update system because updates don't work if Clonk is installed system-wide (with a package manager) under linux. It also wouldn't make sense, because package-managers have their own update mechanism. Whenever the time comes that RPMs, DEBs etc. will be maintained, we need a preprocessor-switch in the source to disable the update system for package-manager-users.