UpdateMechanism

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.

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.

[Info]
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:

http://boom.openclonk.org/server/?action=version

Constructing the UpdateURL

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.)

Interface to the build scripts

(To be written or copied from Newtons word processing file)

Download page

(To be written or copied from Newtons word processing file)

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.