Live Update: Struggling to Understand the Usage/Benefit of Versioned Channels

[derekps]

Hi there!

I am trying to wrap my head around the use of Versioned Channels as opposed to Versioned Build (this is more familiar for me as I am moving from Capgo). I saw this comment and some documentation that all state that Versioned Channels are the recommended approach. However I am struggling to wrap my head around exactly how to implement them.

Let's say that I only want to use Live Updates for SemVer Patch releases - which is entirely reasonable, as you'd expect Minor releases to possibly contain non-HTML/CSS/JS changes such as dependency changes. My thought was that I could create a channel like production-8000 where the 8000 comes from this logic, where I generate a version code from the SemVer version name:

// Get the current version name of the app
const { versionName } = await LiveUpdate.getVersionName();

// Generate a numeric version code from the version name's major and minor version parts
const parts = versionName.split('.');
const minor = parseInt(parts[1], 10);
const major = parseInt(parts[0], 10);
const versionCode = major * 100000 + minor * 1000;

await LiveUpdate.setChannel({ channel: `production-${versionCode}` });

Note: v0.8.0 = 8000 using the above code.

This works, and the app connects to channel production-8000 when my SemVer in package.json is 0.8.0.

In my CI when I want to push a Live Update of v0.8.1 (which should be sent to all users of v0.8.*) I again attempt to create the Channel production-8000 (because I have no way to know if it already exists) and then I create the new bundle on that channel.

Where this falls apart is that Channel production-8000 already exists and my CI dies trying to recreate it. Is there any chance that the app:channels:create command might be made idempotent so we can call it as many times as we like with the same appId and name and it won't blow up?

---

I'd also just generally like to understand if I am thinking about the use of versioned channels in the way that you want us to think about them. And more specifically how they can be used for my scenario outlined above where only Patch SemVer releases should be applied to the app. Here are a few examples of exactly what I mean by only applying Patch SemVer releases.

• v0.8.0 is installed. My app connects to Channel production-8000. The latest Bundle created on Channel production-8000 should always be installed onto my device when I call LiveUpdate.sync(). This could be v0.8.1...v0.8.n
• v0.8.0 is installed. My app connects to Channel production-8000. There are no Bundles created on Channel production-8000 so no updates will be applied.
• ^ Following on from this, if I release v0.9.0 of my app via Live Update and app store, my device will not receive v0.9.0 via LU because it is running v0.8.n and therefore listening on Channel production-8000. Once the device downloads v0.9.0 from the app store it will start listening on production-9000 and will start receiving updates like v0.9.1...v0.9.n

---

That was long, and possibly hard to follow. Please let me know if I can clarify anything. We really want to move off of Capgo, and Capawesome Cloud Live Update looks like it could be the right tool for us if I can nail down the workflow a bit tighter 🙇

[robingenz]

Hi @derekps, first of all, thank you very much for your feedback. It's incredibly valuable.

Regarding your questions:

Where this falls apart is that Channel production-8000 already exists and my CI dies trying to recreate it. Is there any chance that the app:channels:create command might be made idempotent so we can call it as many times as we like with the same appId and name and it won't blow up?

Usually, CI/CD environments already offer a special flag for this purpose, which can be used to ignore the error. Here is an example with GitHub Actions:

- name: Create a channel on Capawesome Cloud
  run: npx capawesome apps:channels:create --appId "..." --name "..."
  continue-on-error: true

However, if this is not a solution in your case, I can add a flag to the CLI. Just let me know.

I'd also just generally like to understand if I am thinking about the use of versioned channels in the way that you want us to think about them. And more specifically how they can be used for my scenario outlined above where only Patch SemVer releases should be applied to the app. Here are a few examples of exactly what I mean by only applying Patch SemVer releases.

Yes, the way you describe it would definitely work. It's important to understand that there are different approaches to using Versioned Channels. For example, many of my clients (including myself) prefer to use the version code instead of the version name for the channels. There you can use a simple number (e.g. 55) that increases by 1 with each native update and you don't have to worry about SemVer. This is also safer than the version name, as the version name can strictly speaking remain the same across different native versions. The version code, on the other hand, must be increased.

In the end, it is simply a matter of setting a channel based on the native app version to prevent live updates that are not intended for this native version from reaching the device. That's what it's all about. Versioned channels are intentionally flexible so that they are not restrictive.

But I realize that I should definitely create more documentation here. I will publish an update in the next few weeks with recommendations and examples.

If you have any other questions, don't hesitate to get in touch.

[derekps]

Thanks for the reply @robingenz 🙇

For my little Capawesome LU PoC I was simply using a shell script to create the channel and bundle, so I did not have access to the nice CI/CD continue-on-error that you've got there, however shortly after posting this question I realized I can just do a || true at the end of my command (i.e. npx @capawesome/cli@latest apps:channels:create --appId a-b-c-d-e --name production-${VERSION_CODE} || true) and it will effectively work the same as continue-on-error: true in your example. So I suppose the idempotent channel creation command is purely a nice-to-have 👌

---

If it's not too much trouble can I probe the versioned channels strategy/documentation a little deeper to further solidify my understanding?

The example in the documentation shows an app running version code 10 listening on channel production-10.
When you create a new release for your app you have to bump the version code to 11, but the app is still listening on production-10. In the scenario in the docs, how would my v10 app ever expect to receive the live update to v11? Am I missing something completely obvious here? 🙈

You mentioned adding more examples in the future which I greatly appreciate. Do you have a recommendation for how you might try to tackle my scenario (the SemVer Patch update strategy) if you were to implement such an approach today?

[robingenz]

If it's not too much trouble can I probe the versioned channels strategy/documentation a little deeper to further solidify my understanding?

Of course!

When you create a new release for your app you have to bump the version code to 11, but the app is still listening on production-10.

No, the app always listens to the channel with the current version code, see:

// Get the version code of the native app
const { versionCode } = await LiveUpdate.getVersionCode();
// Select the channel based on the version code
await LiveUpdate.setChannel({ channel: `production-${versionCode}` }); 

So if I bump the version code to 11, the channel production-11 is automatically set.

Do you have a recommendation for how you might try to tackle my scenario (the SemVer Patch update strategy) if you were to implement such an approach today?

It is best to use the version code as explained. The major and minor changes would then simply be published as native updates and patch changes as live updates. The current SemVer version should be stored in the web build (In Angular, for example, you could use the environment.ts file here).

Example:

Current web build version name: 1.1.0
Current native version name: 1.1.0
Current native version code: 15

1. Publich minor release -> Deploy native Update
	- New web build version name: 1.2.0
	- New native version name: 1.2.0
	- New native version code: 16
2. Next, publish patch release -> Deploy Live Update
	- New web build version name: 1.2.1
	- New native version name: 1.2.0 (since no native Update was deployed)
	- New native version code: 16 (since no native Update was deployed)
2. Next, publish major release -> Deploy native Update
	- New web build version name: 2.0.0
	- New native version name: 2.0.0
	- New native version code: 17

I hope that makes it clearer.

[derekps]

Hey @robingenz ,

Thanks for the deeper explanation. I think I understand where I was getting lost now. Can you confirm my understanding below?

The version code approach seems to work if you don't release Patch releases via App Store. But it seems to fall apart if I intend for all Patch releases to also go out via App Store, because that means I will need to increment versionCode as well as versionName for every release?

In our scenario our preference is that ALL updates go to the App Store as this is how users know and expect app updates to work. In the scenario that we find a bug we need to fix we would create a Patch release that we push via Live Update, but also that fix goes to the App Store. Users may receive the fix via LU or via App Store, depending on which they interact with first. Because it goes to App Store it has to have a versionCode bump. This means that there is no way for an app already deployed on a user's phone and listening on production-${versionCode} to ever receive the Live Update, because the LU will be pushed out of the channel production-${versionCode+1}.

Does that make sense? Am I still misunderstanding?

Have you seen that most people would use Live Updates only for Patch updates, and avoid the App Store for these?

I really appreciate you taking the time to help with these questions, and hopefully they are also beneficial to you for understanding different use cases and how the documentation can be bolstered with some different examples/strategies in the future.

[robingenz]

Many customers actually do exactly this. It's pretty simple:

1. first publish a live update for the current app version
2. now increase the version code and publish a new native update

This way, all customers with the old app version receive a live update and are on the same level as the customers who make a native update. The customers who make a native update no longer receive the live update and that is a good thing, as they are already up to date.

Have you seen that most people would use Live Updates only for Patch updates, and avoid the App Store for these?

Yes, some customers do that, but I also think it's better to release bug fixes as native updates in a timely manner.

I really appreciate you taking the time to help with these questions, and hopefully they are also beneficial to you for understanding different use cases and how the documentation can be bolstered with some different examples/strategies in the future.

Definitely, thank you for all the feedback.

[derekps]

It's pretty simple: first publish a live update for the current app version ... now increase the version code and publish a new native update

Aha! This was the missing piece in my understanding. Our flow historically has been to increase the version code AND THEN release the OTA and push to App Stores. We would need a minor CI tweak to push the OTA first, and then bump the version code before pushing to App Stores.

Thanks so much for all the back-and-forth helping me to nail down my understanding of your product @robingenz 🙇

[robingenz]

@derekps You're welcome! Please get in touch if you have any further questions.