Best practice for autoupdates

Question

For desktop based applications, what are best practices to perform auto updates? Currently, we download all files, then copy and register (if com dll) to their respective directories.

I looked at Google Chrome update method. It seems that it first downloads a zipped file into a directory, and then unzips all the files. Also, they have a setup application which seems to be used to do the update. Additionally, they create a directory mapped to update version like 1.0.154.43, but they keep the old version's directory.

Monjo

Answer 1

The recent blog post from the Chromium team is a great guide:

http://blog.chromium.org/2009/01/google-chrome-installation-and-updates.html

Basically, the same thing is done when you use MS's ClickOnce and I have no problem using applications with such update method so far, so I guess this classify as a "Best practice"... but that's just me.

1. Store each version in its own unique folder.
2. Use a "Launcher" to launch the most updated version available and...
3. Check for any new versions in the background after the application has launched.
4. Download any new version found and make a new folder for that version.

Google Chrome is a little different since they use the Google Update service to do the updating but the overall experience/cycle is pretty much the same.

Your user launch an application, if any new version is available, it's downloaded in the background. And then the next time the application starts, your user gets the new version automatically and (if possible) silently.

Granada

Answer 2

A couple of tips:

• Regardless of how you choose to do it, please don't create a new service or process to check for updates and then leave it on continuously. You know, like Adobe and Sun (for Java) like to do. Regardless of what you're making, I can guarantee that it's not important enough that it needs to be updated every time the user starts the computer. Updates should either be integrated with a standardized update process common to the OS or when the application is running. Updates should not continuously steal system resources or slow down the boot process by default.

• If you maintain separate directories for each version, you need to add code to maintain that. Disk space is not intended to fuel updates. I recall one Citrix application that had 5 different versions on my computer at one time. The user should not see more than two copies (maximum of one backup, confirmed as functional) of your application on their file system unless they explicitly placed them there. Shortcuts to your application can become outdated when the folder location changes like this, so be careful.

• If you update after the program has been started, I would recommend notifying the user in a non-obtrusive fashion. If the update doesn't cause a significant change in functionality, download the update in the background, switch to the new version the next time the application is executed, and notify the user of significant changes (don't use a modal dialog or steal focus). Don't make the user click a button to agree to install updates before launching the app, or force them to restart to use the updated version. Allow users to configure automatic updates, then do it without impacting their productivity. Firefox is rather bad about this, which is sad since it's such an integral application to many users.

• Don't touch the system tray. That should be reserved for useful (to the user) applications. I'd also recommend against balloon notifications, as well. Use something like the infobar commonly seen in browsers. Microsoft applications are particularly bad about using the system tray and balloon notifications to waste user time with unimportant notifications. If the user enabled automatic updates, they really don't need to know that everything is working just as they expected. Tell them when there's something new or useful, and don't force the knowledge down their throats. Leave the changelog under a Help menu item so they can check bug fixes on their own.

• Be careful of updates using the MSI system if you deploy a default configuration file. You don't want to overwrite any user files in your update. In the same vein, if the format of configuration files or user files changes, you should provide a mechanism to automatically backup and upgrade those files. Or start building default settings internally within the application instead of deploying them.

• Be bandwidth conscious. Large files take time and possibly metered bandwidth from your users. Especially if you update daily.

I can't recall a truly non-intrusive update procedure off-hand, but I can recall plenty that have wasted my time and resources in the past. Don't be the guy that makes another.

Cube

Answer 3

Use an existing framework

On MacOS X: use the Sparkle framework, http://sparkle.andymatuschak.org

On Linux:create packages & setup repositories for the distros you will support

Piano