Small cross-platform software update installer
Find a file
Robert Knight 9d3c02e31c Store update-log.txt log file in the correct location under Windows
This is the same location that Mendeley Desktop stores its data files
($LOCAL_APPDATA/$ORGANIZATION_NAME/$APP_NAME)
2011-08-30 10:43:14 +01:00
cmake/modules Move cmake code to generate a C++ source file from a binary data file into a helper module 2011-08-29 17:40:25 +01:00
external Add pre-built zlib library to build tree for Windows builds 2011-08-23 20:38:20 +01:00
src Store update-log.txt log file in the correct location under Windows 2011-08-30 10:43:14 +01:00
tools Change the package-map JSON file into a general config file which also specifies the name of the updater and path to the main binary. 2011-08-27 16:09:11 +01:00
CMakeLists.txt Move cmake code to generate a C++ source file from a binary data file into a helper module 2011-08-29 17:40:25 +01:00
README Add a note in the README file on how to build the updater and customize it 2011-08-29 23:08:34 +01:00
TODO Update TODO file 2011-08-29 21:45:02 +01:00

This tool is a component of a cross-platform auto-update system.
It is responsible for performing the installation of an update after
the necessary files have been downloaded to a temporary directory.

This tool is responsible for:

 * Reading an XML file specifying the contents of an update.
 
 * Extracting and installing updated files from one or more compressed packages.
   
 * Removing any files which are no longer needed in the new version of the application.

 * Requesting elevated priviledges if required to install the update.

 * Displaying a simple updater UI and re-launching the main application
   once the update is installed.

The tool consists of a single small binary which depends only on libraries
that are part of the base system.

The external dependencies of the updater binary are:

 * The C/C++ runtime libraries (Linux, Mac),
 * pthreads (Linux, Mac),
 * zlib (Linux, Mac)
 * native UI library (Win32 API on Windows, Cocoa on Mac, GTK on Linux if available)

To perform an update, the application (or another separate tool) needs to download
the updater binary, an XML file describing the update and one or more zip packages
containing the files for the update to a temporary directory.  It then needs
to invoke the updater, specifying the installation directory, temporary package
directory and path to the update script file.  The updater then installs the
update and restarts the application when done.

Building the Updater
====================

 Create a new directory for the build and from that directory run:

 cmake <path to source directory>
 make

Customizing the Updater
=======================

 To customize the application name, organization and messages displayed by the updater,
 edit the AppInfo class and the icons in src/resources

Preparing an Update
===================

 1. Create a directory containing your application's files,
    laid out and with the same permissions as they would be when installed.

 2. Create a config file specifying how the application's files should be
    partitioned into packages - see tools/config-template.json

 3. Use the tools/create-packages.rb script to create a file_list.xml file
    and a set of package files required for updates.

 4. Upload the file_list.xml file and packages to a server

 After step 4 is done, you need to notify existing installs that an update
 is available.  The installed application then needs to download the
 relevant packages, file_list.xml file and updater binary to a temporary
 directory and invoke the updater.

Delta Updates
=============

 The simplest possible auto-update implementation is for existing installs
 to download a complete copy of the new version and install it.  This is
 appropriate if a full download and install will not take a long time for most users
 (eg. if the application is small or they have a fast internet connection).

 To reduce the download size, delta updates can be created which only include
 the necessary files or components to update from the old to the new version.

 The file_list.xml file format can be used to represent either a complete
 install - in which every file that makes up the application is included,
 or a delta update - in which case only new or updated files and packages
 are included.

 There are several ways in which this can be done:

 Pre-computed Delta Updates
   - For each release, create a full update plus delta updates from the
     previous N releases.  Users of recent releases will receive a small
     delta update.  Users of older releases will receive the full update.

 Server-computed Delta Updates
   - The server receives a request for an update from client version X and in response,
     computes an update from version X to the current version Y, possibly
     caching that information for future use.  The client then receives the
     delta file_list.xml file and downloads only the listed packages.

     Applications such as Chrome and Firefox use a mixture of the above methods.

 Client-computed Delta Updates
   - The client downloads the file_list.xml file for the latest version and
     computes a delta update file locally.  It then downloads only the required
     packages and invokes the updater, which installs only the changed or updated
     files from those packages.

	 This is similar to Linux package management systems.