mirror of
https://github.com/etlegacy/Update-Installer.git
synced 2024-11-24 21:01:27 +00:00
Add additional documentation on hosting and delivering updates.
This commit is contained in:
parent
f16ee82f24
commit
47d79bcc6c
2 changed files with 38 additions and 0 deletions
2
README
2
README
|
@ -62,6 +62,8 @@ Preparing an Update
|
|||
relevant packages, file_list.xml file and updater binary to a temporary
|
||||
directory and invoke the updater.
|
||||
|
||||
See doc/update-hosting for more details on hosting and delivering the updates.
|
||||
|
||||
Invoking the Updater
|
||||
====================
|
||||
|
||||
|
|
36
doc/update-hosting
Normal file
36
doc/update-hosting
Normal file
|
@ -0,0 +1,36 @@
|
|||
This project includes a tool for installing updates and specifies an XML-based
|
||||
file format for describing the contents of a release. It does not include
|
||||
the client-side tools to detect the availability of updates, download
|
||||
updates that are found and invoke the update installer. It also does
|
||||
not include the relevant server-side components. You will need to write
|
||||
tools to do this.
|
||||
|
||||
The simplest option is to create, for each platform, a file_list.xml file and .zip
|
||||
file containing the complete contents of the application on that platform.
|
||||
|
||||
1. Modify the file_list.xml file generated by the create_packages.rb script
|
||||
to include <source> URLs specifying where to download the packages from and
|
||||
then upload this modified file_list.xml file plus the compressed .zip packages to a server.
|
||||
|
||||
2. The client application should then periodically fetch the file_list.xml for the latest release
|
||||
from a fixed URL (eg. http://www.yourdomain.com/updates/$PLATFORM/file_list.xml)
|
||||
and check whether it is newer than the installed version, by checking the <targetVersion> element in the file.
|
||||
|
||||
3. If a newer version is available, the client should download the updater and .zip packages to a temporary directory
|
||||
and invoke the updater to install the new version.
|
||||
|
||||
A more sophisticated option is to store the file_list.xml file and packages for each release
|
||||
on the server. When the client checks for an update:
|
||||
|
||||
1. On the server, determine whether a newer version is available and if so,
|
||||
determine the target version for the update. If you want to have multiple 'channels'
|
||||
of updates (eg. stable channel, beta channel, development channel) then you can change
|
||||
the target version depending on which channel the user is in.
|
||||
|
||||
2. Parse the file_list.xml for the client's current version and the
|
||||
target version and generate a delta file_list.xml file listing only the
|
||||
packages and files that have changed.
|
||||
|
||||
3. Return the delta file_list.xml file to the client, which then downloads the necessary
|
||||
packages and installs the updates.
|
||||
|
Loading…
Reference in a new issue