React-native-code-push: Question: if you set targetBinaryVersion for a release, will subsequent releases require at least that version?

[stueynet]

Sorry but this is only a question. I hope this is the appropriate forum for it. We are getting our workflow organized and I had worried about apps that had not updated via the app store, download code-push releases that were incompatible with their Binaries. I can see that setting targetBinaryVersion solves this problem. But I am wondering, once you push a release with targetBinaryVersion set, when you push subsequent releases should you always set that?

So we may have a release that invoices core module updates in which case we would want to set the targetBinaryVersion. But then a subsequent release may be just a simple javascript patch or image update. If we don't set it on those subsequent releases, will people who don't meet the previous targetBinaryVersion still get the new update and thus have a breaking app?

[max-mironov]

Hello @stueynet - you are right, that is a good place to ask questions about codepush :)
So in general the rule for determining correct target binary version is as follows:
if you do not specify it explicitly than it will be fetched automatically from corresponding plist file for iOS and build.gradle for android. The logic for getting AppVersion could be found here.

In other words you should set target binary version parameter in case you want to override the version that is defined in plist/build.gradle or if you want to address a wider range of AppVersions to which codepush updates should be applied.

More info regarding target binary version parameter is here.
Please feel free to ask questions if any.

[stueynet]

Thanks @max-mironov. So just to be 100% clear. Setting the targetBinaryVersion will literally only install that particular codepush deployment on devices that have that exact binary version. Then when you push a subsequent build with no targetBinaryVersion set it will be installed on all devices.

Again I see the issue being that given we can't control exactly what binary a user happens to be on, pushing codepush releases that have a dependency on a particular core update might be hard to manage.

[max-mironov]

@stueynet
Yup, you are right:

Setting the targetBinaryVersion will literally only install that particular codepush deployment on devices that have that exact binary version

For this one:

Then when you push a subsequent build with no targetBinaryVersion set it will be installed on all devices.

Correct thing is that it will be installed on all devices that much target binary version that will be fetched by default from info.plist/build.gradle.

With that said I think it could be reasonable to have e.g. the following workflow:
1) You should always bump app version when making binary changes/changes that could be incompatible with previous codebase
2) You could release code push update targeting the older app versions with specifying --targetBinaryVersion parameter
3) You can omit this parameter if you would like to target the binary version that is currently specified in your info.plist/build.gradle files.

Please let me know if you have more questions.

[stueynet]

@max-mironov does info.plist/build.gradle get included with a codepush release though? I thought that would only come through with a full app store release. If not then this is not an issue at all.

[max-mironov]

@stueynet, no this files will not be included in codepush release at all.

[stueynet]

Right so the issue remains that if you are pushing through codepush, once you push a codepush (js and images) release that has dependencies on a new binary, you have an ongoing issue. The issue being someone with an old build (that has not updated the app from the app store), will continue to get codepush updates that may in fact be dependant on a binary build update that they don't have.

[max-mironov]

@stueynet
Yes - that could be an issue if all your codepush updates are targeting the same binary version.
To avoid this situation you should try to distinguish updates that could have incompatible changes with AppVersion parameter to avoid confusion.
But on the other hand if you push changes to binary (that could introduce some kind of incompatibility) you should anyway bump version number and release new AppStore update due to this changes could not be applied via codepush only.

[stueynet]

For sure. The issue is that the app store updates are not guaranteed to be installed. So imagine a user that has binary 1.4.9 installed. Then we push a codepush deployment. As long as the codepush deployment has no binary dependencies no problem. However when we push a new release like 1.5.0 which has a new native module that corresponds to the js updates, we want to make sure that we have set the codepush release to require the 1.5.0 binary. So thats fine too. However what happens when we have the 1.5.1 codepush release? The people that still have 1.4.9 binary will not have the required files. So when we codepush 1.5.1, people who have not updated via the app store since 1.4.9 will break. See how you get stuck?

[max-mironov]

@stueynet
Ok, so I believe the following should work for you:
1) You have AppStore version 1.4.9. You also have CodePush with target binary version 1.4.9. So far so good.
2) You have new AppStore version 1.5.0. Also produced new CodePush update with target binary version 1.5.0.
At that moment all users that are using 1.4.9 will receive CodePush updates 1.4.9, for those who are using 1.5.0 CodePush updates targeting 1.5.0 will be applied.
3) You produce new AppStore version 1.5.1 (I assume so because CodePush update targeting 1.5.1 doesn't make sense without the app with corresponding app version). And after that produce new CodePush update for version 1.5.1.

So here we have the current state:

• CodePush update for 1.5.1 is applied only to AppVersion 1.5.1.
• Older app versions (1.4.9 and 1.5.0) do not receive incompatible update 1.5.1 (because this update is not targeting their binary version).
• As long as someone updates the app version on the device manually (say from 1.5.0 to 1.5.1) all previous CodePush updates are cleared and only updates that are targeting 1.5.1 would be applied.

In other words updates that are targeting different binary versions are completely isolated and could not break the app somehow.
Please let me know if I'm missing something here.

[stueynet]

The only thing that is missing is that the above workflow requires you match a binary version with every codepush. Once you have a codepush release attached to a specific binary version, all future code push releases must always target a specific version. You can no longer just do codepush release because 1.4.9, 1.5.0, 1.5.1 would all get the new release that has the 1.5.1 minimum dependency. And all future releases will also have that dependency until you make a new binary change which will bump the dependency.

This is why we have an API check where we can actually set the minimum build number the app must have to enable codepush.sync().

But in generally I don't see a workflow where you can just push to code push without specifying a specific binary version number.

[max-mironov]

@stueynet
Yes, it is strongly recomended not to use some kind of ranges like say targetBinaryVersion=* because this could lead to compatibility issues. Or at least you should know what you are doing and why you need this.

For this one:

Once you have a codepush release attached to a specific binary version, all future code push releases must always target a specific version

Why do you see a problem with this? There is no need to specify it manually because our CLI in smart enough to fetch this automatically.
Also from my point of view it make sense to scope codepush update to specific version.
What is the purpose for your new update to target old versions? But it is good that you have an ability to provide a fix for older versions with targetBinaryVersion if needed, do you agree with me?

So for this:

You can no longer just do codepush release because 1.4.9, 1.5.0, 1.5.1 would all get the new release that has the 1.5.1 minimum dependency

This is not clear for me. You need to do CodePush release that has 1.5.1 dependency (and so I assume you bump version number in the app)? If you already bump it - no worries, it will target correct version. If not - you have a choice to set it manually via targetBinaryVersion.

So finally that's true - in general you cannot just produce new release without specific binary version especially if you have breaking changes. The versioning here for rescue. Also I believe that this is one of the main purposes of versioning - help us to designate which update we should apply to which version.

[stueynet]

So finally that's true - in general you cannot just produce new release without specific binary version especially if you have breaking changes.

Yeah we are on the same page for sure. You would always target a binary version and thats way more stable anyway. I just hadn't though much about it before but it does make perfect sense to me now. Thanks so much for all the help!

[max-mironov]

No problem @stueynet, you are always welcome :)

[stueynet]

So one more question sorry... If we want to target the current latest release in the app store for a codepush update, we would target 1.5.1 (to hit current users of the latest version) but also have to target 1.5.2 at the same time?

[max-mironov]

@stueynet
If you need to target several versions at the same time you could use range for this.
Although you must understand all the risks that we have discussed above but it is still possible to target several versions at the same time. You could do it e.g. the following way:
code-push release-react AppName PlatformName --targetBinaryVersion=1.5.1-1.5.2

[stueynet]

Yeah that’s perfect. If you have to hit fix a release that’s already on devices, I don’t see any other way because you’ll want to apply it to the binary version that’s already out there, plus the one that will be released when the App Store gets around to approving the hot fix release.

[stueynet]

I am not re-opening this ticket but wanted to confirm the confusion now that I have a better understanding. It was unclear that when you do codepush release, it automatically associates that codepush deployment with the current binary version. I thought it would simply update the bundle, and any device would want to go and get it. However based on the above, all code push release only targets the binary version of the app, based on when you do the release.

So one final summary here:

1. Release 1.5.1 to the app store. Everyone has 1.5.1 binary and codepush for 1.5.1.
2. Find a bug in 1.5.1
3. Update the js code and codepush release BEFORE you version bump. So this will update all devices currently running version 1.5.1.
4. Version bump and release the full build to the app store. That will target devices only with 1.5.2.

The important thing is that you dont version bump when you release the hotfix that fixes 1.5.1. OR you add the targetBinaryVersion=1.5.1 when you codepush release the hotfix.

So key take way for me is that every codepush release is automatically tied to the binary version in the local codebase from where you push the codepush release.

[max-mironov]

Hello @stueynet
Yep, you are right:

all code push release only targets the binary version of the app, based on when you do the release.

And you don't need to add targetBinaryVersion if your current application targets the desired version. Otherwise you could specify it directly.

So key take way for me is that every codepush release is automatically tied to the binary version in the local codebase from where you push the codepush release.

Yes, that is correct.