Updating CommCare Content is the process of getting the version of your applications resources (XForms, Translations, menus) onto a device. This is what needs to happen if you've changed your application on CommCare HQ and want to get that version on a phone.
Note: Updating the CommCare software is different from updating a CommCare application!
There are two components to CommCare:
1- the CommCare software which is the the shell of the program. CommCare mobile client is the same for all projects.
2- the CommCare content which is often referred to as the "application" (forms, case management, multimedia, etc.)
These instructions are for the application content component. For instructions on updating the CommCare software, see this page.
Making Releases ("Starring" Builds) for Updates
Since you can make a build of your app at any time for testing purposes, it is important to be able to mark which version of your application you want to see put on devices in the field when they update. We refer to this as releasing a build. In CommCareHQ, you can do this by clicking on the empty star next to a build once you've had a chance to test it out and make sure that everything is working as expected. This signifies that the app is ready to be installed.
When looking for updates, CommCare apps will look at the latest, released build. If an application is already updated to (or was installed with) the newest build which has been starred, it won't update, even if newer (unstarred) builds have been created. If the latest released build's version is lower than the installed build, an update will not occur. If, for example, the last release was version 70, the currently installed build is version 73 (for testing and development) and there exists a newer unstarred build 74, the app will not attempt to update. If 74 is released, the current build will update the next time it checks.
Currently, the release status of a build is only used in remote updates of applications, but in the future may be used for things like cleaning up applications (purging older, non-released builds, for instance), and it is generally a good idea to star builds which are distributed in order to keep track of them.
CommCare can be configured to check for updates on a regular schedule. This is specified by the Auto Update Frequency setting in the CommCare Properties section of the settings UI. When set to auto-update, CommCare will attempt to check CommCareHQ for new resources on a daily or weekly schedule. This check occurs immediately after login, but before the user is taken to the home screen. If updates are found, the user may or may not be asked whether they want to download them, depending on the app's configuration. If the app does not ask, it will simply attempt the update any time one is found.
If the app can't contact the server, it will try again on a future login.
A manual update can also be initiated from CommCare.
Log in and press the menu button. Select Update CommCare
Video available here
Login as "admin" or a user with admin rights, and from the home screen navigate to Settings -> Check for Updates or in the login screen go to Options -> Tools -> Check for Updates
When new features are added they are generally added to Major and Minor updates to CommCare. If an application on HQ is moved to a higher Minor or Major version number (1.2 -> 1.3 for instance), an application's resource files won't be able to be downloaded by an older version of CommCare.
Advanced Software Upgrades
Since CommCare's resources are almost always included with the application files, upgrading CommCare often happens at the same time as the Application Resources are updated, and as such a full re-installation should be used to update both at the same time (see note below). This method of upgrading is not fully supported, but can be used by experts.
In-Place upgrades basically involve installing the applicaiton onto the phone without first removing the old version. This is possible using the OTA, Phone-to-Phone, and Memory Card installation techniques. It is never recommended unless you are using a completely offline deployment, or in specific future use cases where OTA installation is being used to manage remote upgrades.
The below are guidelines for the minimum that should be required when performing an upgrade. Keep in mind that the safest way to upgrade an app is to always follow the full re-installation instructions.
Major Version (1.N.N -> 2.N.N)
Major version bumps will first require the migration of your application's resources to the newest version using CommCare HQ. Once a build of the app is available on the newest version is available, you should follow the full re-installation instructions.
Minor Version (1.1.N -> 1.2.N)
Minor version bumps shouldn't require any changes to your application resources (although they will often permit you to include new features in them), simply create a new build with the existing resources and perform a full re-installation.
Maintenance Version (1.1.1 -> 1.1.2)
Maintenance releases are generally designed to be safe for an in-place upgrade on top of the old app (generally in order to correct bugs with OTA upgrades, although this feature isn't widely usable yet). However, a full re-installation is still recommended.