Allow developers to override cordovaCompatibilityVersions

[denisbabineau]

_4 Upvotes_ Current compatibility check for Hot Code Push to mobile blocks any updates if any of the cordova components' versions were bumped.

We need a way to override this default. See discussions at:

https://forums.meteor.com/t/cordova-app-android-not-reloading-after-hot-code-push-with-deployed-app/16336/38

suggested solution by @martijnwalraven

I think the solution is to allow developers to override cordovaCompatibilityVersions (the same way we allow AUTOUPDATE_VERSION to be defined manually). This way, you could set it to the current value when adding new plugins so hot code push won't be blocked.

[hlehmann]

+1 I don't see the need for cordovaCompatibilityVersions check. I'am having trouble when I pubish ios and android not in the same time.

[mikepaszkiewicz]

did a little exploring, would this modification in isobuild/bundler.js / line 1369 be a potential way to override?

const hash = process.env.CORDOVA_COMP_VERS || WebAppHashing.calculateCordovaCompatibilityHash(
            version,
            this.cordovaDependencies); 

[blouze]

+1 went through hell to find out why HCP was not working for me... Could not find why hashes differed in prod though.

[levinse]

+1 this will be a major problem for us once we switch to 1.3.

It's not really practical to block HCP if cordova plugins have different versions because it's a major barrier to high release velocity.

We're used to handling different versions within the app client/server code and we routinely have 1-2 older versions of clients as well as differing versions of iOS vs Android live in the App/Play stores. By letting us continue to handle these differences within code, as was the case with 1.2, we're able to continue to release the app to our app servers and via HCP much more rapidly (multiple times per day currently). There's no actual reason to prevent HCP if we're able to handle such differences within code. Without HCP, we're blocked for days waiting for Apple to approve a release, which significantly lowers our release velocity.

[martijnwalraven]

@mikepaszkiewicz: Yes, I think that is where you'd want to override the versions. But since versions differ between platforms, and you'll need to specify the current version to enable hot code pushes, you'd need to find a way to pass versions for both platforms.

[crazybaud]

@martijnwalraven Do you have any UX plan for this issue ? For example :

• show some kind of 'Upgrade via App Store Please' dialog to older clients.
• remove cordovaCompatibilityVersions functionality
• set minimun version number, server side

Is someone working on a PR ? How can we help ?

Meteor is great. This issue is a nightmare for us.

[martijnwalraven]

@crazybaud: No, I'm not working on this and I'm not aware of anyone who is. So if you have good ideas on how to improve the compatibility check functionality, feel free to open a PR!

[erikanthonywall]

@crazybaud You can use the WebAppLocalServer.onError function to listen for the "Cordova platform or versions changed" error and handle it appropriately. In my app I'm redirecting the user to a "Version not supported, please update your app" view.

[levinse]

Are there any updates on this? We didn't complete our then-1.3 upgrade in the summer because of the WKWebView WSOD issues and are about to go to 1.4 but I see this is still an issue on 1.4.

[avesus]

The best way to handle this would be trying to install the new version and monitor for any errors. If those appear, do rollback. Standard production deploy workflow, isn't it?..

[markshust]

@avesus I'm not sure you understand the problem. If you install meteor, and add a Cordova plugin, simply updating the Cordova plugin package a minor bump blocks hot code reload.

[wojtkowiak]

@denisbabineau this is now available in 1.4.4.2 with METEOR_CORDOVA_COMPAT_VERSION_IOS, and METEOR_CORDOVA_COMPAT_VERSION_ANDROID env vars. Can this be closed?

[hwillson]

Closing as #8581 was merged. Thanks all!

[markshust]

Can we get documentation added someplace on how to use this? That is absolutely great this is in core now, but I have no idea how to use it ;)

[wojtkowiak]

@abernix would you like a note in the docs somewhere about it?

@markoshust it is just simply using env vars. So to override the version you just use:

METEOR_CORDOVA_COMPAT_VERSION_IOS=1234 meteor build ...

Or to build version with and without crosswalk and still receive HCP on both you can just use:

METEOR_CORDOVA_COMPAT_VERSION_EXCLUDE=cordova-plugin-crosswalk-webview meteor build ...

[markshust]

@wojtkowiak thank you, the EXCLUDE envvar is pretty self-explanatory and what I need. any reason to also not add in something like this? I handle cordova compatibility in code and never want HCR blocked.

METEOR_CORDOVA_COMPAT_VERSION_EXCLUDE=*

Regarding the iOS and Android envvars, I'm not sure I understand how those two work. I know I can set it to some value, but what does that value do? What happens when I change it? This and AUTOUPDATE_VERSION should really be in he meteor guide. I finally understand autoupdate version but it wasn't too apparent at first.

Thank you, this functionality is very much needed! Very happy 😀

[wojtkowiak]

I handle cordova compatibility in code and never want HCR blocked.

The compatibility version is the only factor taken into account when the app decides whether it want to receive the hcp update.
So just maintain METEOR_CORDOVA_COMPAT_VERSION_IOS and METEOR_CORDOVA_COMPAT_VERSION_ANDROID set to the same value every build, this would be basically the equivalent of METEOR_CORDOVA_COMPAT_VERSION_EXCLUDE=*

[wojtkowiak]

What happens when I change it?

You will intentionally block HCP as your mobile apps will have different compatibility version.

[markshust]

@wojtkowiak ok great, thanks much for the explanation! absolutely needs to be added to the meteor guide as this is a pretty big issue :) I'll try to make a PR for that. cheers

[skirunman]

Hi @markoshust and @wojtkowiak , did this get added to the Meteor Guide? Thanks!!!

[mikepaszkiewicz]

Can you pass the env var to meteor deploy as well?

[mikepaszkiewicz]

So I tried this by setting this in my startup server code, and deploying did not override what's in my manifest.json. Any ideas?
process.env.METEOR_CORDOVA_COMPAT_VERSION_IOS = 'test';

[wojtkowiak]

setting this in my startup server code

You mean in code like setting it through process.env?

It needs to be present while the project is building so you need to have it before your code is executed.
Best way is to declare it with meteor command.
METEOR_CORDOVA_COMPAT_VERSION_IOS=test meteor or
METEOR_CORDOVA_COMPAT_VERSION_IOS=test meteor build

[mikepaszkiewicz]

So where I'm getting mixed up is there's no mention of deploy? Should I set these same environment variables before meteor deploy? Further, these keys should be set in /__cordova/manifest.json after deploy?

[wojtkowiak]

Hmm I've never used meteor deploy... is that doing the build locally or on the remote server? If it does build locally then it should work. Yes you should see that value in the manifest if it worked correctly.

[skirunman]

@mikepaszkiewicz Just curious if you got this working by setting the environment variable METEOR_CORDOVA_COMPAT_VERSION_IOS=test in Galaxy as you are using meteor deploy as per the Galaxy guide by setting this in your settings.json file?

[mikepaszkiewicz]

@skirunman Duh...should have thought of that one. Going to give this a try later today and will report back.

[abernix]

The build for Galaxy is not done on the server, but rather on the client in the same way that meteor build works.

Therefore, I'd expect that METEOR_CORDOVA_COMPAT_VERSION_IOS=test meteor deploy would be the way to do this (or on Windows, using the method appropriate for setting an environment variable in your shell, then executing meteor deploy).

[Wade-BuildOtto]

This is still been poorly explained on how to implement, I added it to the deploy string no problem, but the Build script it just kicks back an error. Where do I put it for Building the app.

EDIT: Must of been some other kind of error, seems to of built this time.

[alextondello]

I'm trying to make it work for Galaxy. No success so far... Nothing seems to work.

I've tried adding the variables to settings.json:

"galaxy.meteor.com": {
    "env": {
      "ROOT_URL": "XXX",
      "MONGO_URL": "XXX",
      "METEOR_CORDOVA_COMPAT_VERSION_ANDROID": "test",
      "METEOR_CORDOVA_COMPAT_VERSION_IOS": "test"
    }
  },

And I've also tried to set these variables when calling the command to deploy to Galaxy:

DEPLOY_HOSTNAME=galaxy.meteor.com METEOR_CORDOVA_COMPAT_VERSION_ANDROID=test METEOR_CORDOVA_COMPAT_VERSION_IOS=test meteor deploy XXX --settings settings.json

None of this worked. I'm still seeing wrong hash codes in __cordova/manifest.json

Any ideas on how to do it the right way?

[alextondello]

@skirunman and @mikepaszkiewicz did you make it work in Galaxy?

[skirunman]

I have not tried this, but it sounds like what @abernix was saying is just to deploy as per your last example METEOR_CORDOVA_COMPAT_VERSION_IOS=test meteor deploy XXX --settings settings.json. Sorry can't be more helpful.

[abernix]

@alextondello What version of Meteor are you trying?

[alextondello]

Thanks for the tip @abernix! I was running 1.4.2.3 and didn't realize that #8581 came after. Now I'm running 1.4.4.3 and everything is working perfectly.

[advancedsoftwarecanada]

I'm having a LOT of difficulties with this. None of my iOS, Android or PC apps are updating.

I have my Mac building iOS and Android, I've sent the environment variables there.

I have my PC building the web server, which also has the environment variables.

I have my web server, that also has the environment variables there.

Still with all this, it doesn't work. Running Meteor 1.5.1? This is a total nightmare.

www.StarCommanderOnline.com - how do I check what settings I'm supposed to block in the first place? This is very poorly documented, and a very high impact feature.

[markshust]

@AndyNormore I agree that the documentation is bad. However, this is definitely working for me. Here's how I set it up. In my build script (ex. ./.builddeploy):

METEOR_CORDOVA_COMPAT_VERSION_IOS=2.9
METEOR_CORDOVA_COMPAT_VERSION_ANDROID=2.9

METEOR_CORDOVA_COMPAT_VERSION_IOS=$METEOR_CORDOVA_COMPAT_VERSION_IOS \
METEOR_CORDOVA_COMPAT_VERSION_ANDROID=$METEOR_CORDOVA_COMPAT_VERSION_ANDROID \
  meteor build ...

By setting version 2.9 for both ios and android packages, I'm telling Meteor that version 2.9 is hot-code-push compatible with this build. So if I do change a cordova plugin, the current version on the user's mobile device is 2.9, I push out another version that is 2.9, so the client's code accepts this version as the same hash and executes the hot code push. If I were to change this to 3.0 and create another build, the client's version 2.9 doesn't match the new version of 3.0, so the hot code push will be prevented from executing.

Note that the only place you need these environment variables set is when creating the build with meteor build command. You don't need them on the server. Since you are using two different computers for building, make sure you are setting the same values on both build devices. Note also that I do find it awkward that you are using two machines for build -- it's much easier if you just use one device (your mac) to build everything once. Perhaps this is why it isn't working. Good luck!

[advancedsoftwarecanada]

I got it working. I'm not sure exactly which settings worked, but I do know this...

ITS IMPORTANT TO RUN THE SERVER, IOS and ANDROID APP FROM THE SAME BUILD DEVICE

I have a Mac that builds iOS and Android. My windows machine was building the Web app for the .com

Even with all these settings, the code EXACTLY the same, just built on different machines - changes the outcome of settings.

I discovered this when my windows machine crashed, so I built on the Mac and bam, it started working.

[advancedsoftwarecanada]

It's been 5 days since I got it working. I was in heaven. It was great.

But, now my iOS app will not update. Android is working perfectly fine. I haven't changed any plugins, I've been very careful not to change anything.

Sigh...

There needs to be a much more simple method for this..

[advancedsoftwarecanada]

If I'm going to debug this, how do something like this in my app?

version_helper(){ return cordova.app_ios; }

So I can put this in the template and visually identify what the iOS / Android apps have been set to?

[mexin]

I'm having issues that some clients aren't being updated, but this happens when using meteor-desktop, is there any way to overcome HCP not getting to those older versions? seems some of our clients are updating correctly, but some are having problems and are stuck on older versions. so anyway just to force the updates?

[filipenevola]

Hi @mexin this new guide about HCP could help you https://guide.meteor.com/hot-code-push.html

If you are still having issues please open a new issue.