User Tools

Site Tools


mozilla-devel:deploying_automatic_updates

Automatic updates for the staff client are wonderful, provided you know how to deploy them. For basic information on building the staff client you should see Building the Staff Client.

Initial installs

If you want to support partial updates you should go through the process of making updates even on your first install. As a side benefit you get a pre-made windows client.

Partial updates are "changes only" updates that are a lot smaller and faster to apply. Supporting them will make your users happy.

New Client Versions

When building a new client for update purposes you need to make sure you are deploying a newer version than the one you have deployed. This is controlled by the STAFF_CLIENT_VERSION=? portion of the make process (Evergreen install or staff client build).

The full nitty-gritty of "is this newer than that" is covered at https://developer.mozilla.org/en/Toolkit_version_format but in general split the version on the periods between the components, then split each component into number and text parts. Working from left to right compare each piece. Empty number slots are considered equal to zero, empty text parts are considered greater than filled text parts. Thus, 2.2alpha1 is newer than 2.2alpha and 2.2alpha0 (both of which are considered equal), but is older than just 2.2 without the alpha.

If your version number isn't "newer" the client may refuse to update.

To check the last version you used you can check the PREV_VERSION file in the staff_client directory:

cat Open-ILS/xul/staff_client/PREV_VERSION

My recommendation is to increment the last number during minor updates, and only when upgrading to a newer actual release update the other components. MVLC also adds "mvlc" to the third part of the version to differentiate our clients from the official ones, for example:

2.2.0mvlc.0

Stamp IDs

The default for Stamp IDs is to build one automatically based on the version number. It is recommended that you do not specify one manually, but it is possible, and is done with STAFF_CLIENT_STAMP_ID=? when installing Evergreen or building the client.

The Stamp ID is used as the folder in /openils/var/web/xul/ that the staff client connects to. If you don't have a folder corresponding to the one the client is using the client reports that it isn't compatible with your server.

If the client's stamp isn't available on the server and the client has automatic updates enabled the client will prompt the user to forcibly check for updates.

Also, like versions, there is a PREV_STAMP_ID file:

cat Open-ILS/xul/staff_client/PREV_STAMP_ID

Building for updates

There are three situations for upgrades:

  1. Staff client and server upgrades, where the staff client and server code have changed
  2. Server only upgrades, where the staff client code hasn't changed
  3. Staff client only upgrades, where the server code hasn't changed

Upgrading both is the same as any other upgrade cycle, but Server and Staff client only upgrades can be done specially.

Server only upgrades

These are the easiest, as you have no reason to deploy a staff client update. These apply even if staff client code changed so long as the changes were in the Open-ILS/xul/staff_client/server folder only.

The easiest solution here is to use something like this:

make STAFF_CLIENT_VERSION=`cat Open-ILS/xul/staff_client/PREV_VERSION` install

For extra insurance you could add the stamp too:

make STAFF_CLIENT_VERSION=`cat Open-ILS/xul/staff_client/PREV_VERSION` STAFF_CLIENT_STAMP_ID=`cat Open-ILS/xul/staff_client/PREV_STAMP_ID` install

Staff client only upgrades

These don't even require a restart of services, but do require some more options at build time. From the Open-ILS/xul/staff_client directory you can build and install the staff client without rebuilding the rest of the software:

make WEBDIR=/openils/var/web STAFF_CLIENT_VERSION=? server-xul

Or, with an explicit stamp:

make WEBDIR=/openils/var/web STAFF_CLIENT_VERSION=? STAFF_CIENT_STAMP_ID=? server-xul

Don't forget to update the server symlink, and you still need to deploy the updates themselves.

Prepping the updates

Once you have your server-side folder in place you need to build the updates themselves. This is done from the Open-ILS/xul/staff_client directory. If you want things like per-machine registration or a developer build you may wish to re-build the client first (see Building the Staff Client).

Take note, building updates reads from and writes to the /openils/var/updates folder, so you will need to run these commands as a user who can do so.

Once you have the build you want to generate updates for you need to generate the updates. The easiest solution is to generate all the updates in one shot:

make updates-client

That will generate updates for Windows, Linux, and generic clients, build the Firefox 3 extension, and build updates for any versions you have in your updates archive.

Optional compared to Forced updates

By default your update will be "optional" and the client will download it using spare bandwidth, applying it at some point in the future. This is suitable for minor changes that you don't feel need to be forced on your users.

Sometimes you are fixing a significant bug, however, or something else changed on the backend makes the old code incompatible with the new server code. Then you need to force the update.

Forcing the update is as simple as removing the folder(s) for the previous version(s) from /openils/var/web/xul/. Without those folders the client will be unable to log in and will, when automatic updates are enabled, prompt for an immediate update.

Manual update downloading

Once updates have been built the /updates/manualupdate.html file on your server will link to the various downloads for manual updating. In the event of failed updates on clients a link to that page should be provided for the user's benefit. That is also where you can get a copy of the built windows installer for distributing to your users (if you don't just point them at that page to begin with).

Removing Old Versions for Partial Updates

The more previous versions you generate partial updates for the longer the building of updates will take. It can thus be beneficial to remove old versions from your partial support list.

This is easily accomplished by clearing out old .mar files from /openils/var/updates/archives/ (and subfolders thereof).

mozilla-devel/deploying_automatic_updates.txt · Last modified: 2013/02/25 12:40 by gmcharlton

© 2008-2017 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a member of Software Freedom Conservancy.