OTA - Rollback & Downgrades

Downgrading by Upgrading

If a problematic version is deployed to the field, the recommended strategy is as follows.

A cohort is set to version 1.0.0, and a release is deployed of 1.0.1. The 1.0.1 release is identified as problematic, and we need to pull it.

1. Abort the deployment: this is done in the Cohort management section of the Web UI, by clicking the "Abort" button from the "Release Activation" edit:

   

   At this point, some devices will be on the pulled release (1.0.1 in this example), and some will likely still be on the prior release (1.0.0).

2. Generate a higher version number release (1.0.2) with the fix.

   • This can be as simple as re-generating the prior release version (1.0.0) with a new, higher version number; be sure to make sure the new release version is a compatible update with the pulled release.

   • Alternatively, if a proper fix is identified, a new release version can be generated with the fix.

3. Deploy the new release version to the cohort. This will update devices on both the pulled release, and the prior release. No new devices will receive the problematic release, 1.0.1.

Force Downgrading

By default Memfault will not allow downgrading to a previous OTA Release (eg 1.0.0 → 0.9.0).

This behavior can be overridden by navigating to the cohort Settings tab and selecting the "Disable Version Checking" option:

caution

When enabling this mode, be sure to consider the following:

• Any on-device config (settings) data needs to be forwards/backwards compatible, depending on if a downgrade is initiated on a device.

• Sub components (companion ICs, modems, etc) need to be forwards/backwards compatible if present in the system. If these components are also updatable, ensure they can be downgraded as well if enabling downgrades for the system.