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.
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.
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:
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:
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:
There are three situations for upgrades:
Upgrading both is the same as any other upgrade cycle, but Server and Staff client only upgrades can be done specially.
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
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.
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:
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.
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.
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).
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).