Live Update: Avoiding Live Update Rollbacks with resetOnUpdate

[luisbytes]

Currently, with resetOnUpdate enabled, when a new update is downloaded from the store, that new bundle becomes active. However, there's a scenario where this might not be desirable, and I'd like to explain it as clearly as possible.

Let's consider the following scenario:

• Version 2.0.0 is released in the stores.
• Later, version 2.1.0 is released in the stores and also as a live update. This version is not mandatory, so many users remain with the 2.0.0 binary but with the 2.1.0 live update.
• A week later, version 2.2.0 is released, but only as a live update. At this point, the version available in the store is still 2.1.0.

Now, let's suppose a user has the 2.0.0 binary and the 2.2.0 live update installed. This user becomes aware that a new version (2.1.0) is available in the store and installs it. With resetOnUpdate enabled, the user would revert from the 2.2.0 live update to the 2.1.0 binary, effectively rolling back the live update version.

A temporary solution would be to force the re-download of the 2.2.0 live update, but this seems unnecessary since the user has already downloaded it, and it would consume additional bandwidth.

I'm wondering what a definitive solution to this issue would be. Currently, the plugin doesn't manage a version identifier other than bundleId. In the case of the Cloud, this is a random ID.

My suggestion is to implement a resetOnUpdate only if the binary version is greater than the last downloaded live update version. This would involve the plugin identifying and validating live update versions using semver.

What do you think? Is there a more efficient solution?

[robingenz]

The Live Update plugin is designed to make the distribution of live updates as easy as possible. We have therefore consciously decided against the semantic versioning approach. The recommended workflow is Versioned Channels. Live updates are published in a versioned channel. This versioned channel contains the native version number in its name. Only updates that are compatible with the corresponding native version are published in this channel. As soon as a change is made to the native platform (e.g. installation of a new plugin), a new native version must be published and a new versioned channel created. This means that a live update is always compatible with exactly one native version. Therefore, the scenario you described can never occur. It is generally not necessary to publish a native update if a live update is sufficient.