Hello everyone! 
What do you want here, Daniel, you ask? Thank you for asking, to put it simply:
I HOPE WE CAN COLLECT ALL THE INFORMATION ABOUT THE HCP WE KNOW & MAKE THIS THE ULTIMATE FAQ / FIX-MY-HCP - THREAD.
If we find some good answers / hints, Iâll gladly reformat this later on or try to piece it together to one helpful FAQ (or maybe an article for the guide / a readme somewhere or somesuch).
I am but a humble developer from Germany. For many summers I am developing for / with Meteor now.
Most of the systems and mechanisms I know well enough to be dangerous (and sometimes even helpful) or, if not, know that I can find all the documentation and/or forum posts, Git-Issue-Tickets, Stack-Overflow-Pages or what have you.
The one thing which seems to elude me almost completely is - the âHot Code Pushâ (aka âHCPâ), especially in as used in Cordova⢠- Apps.
The docs I can find so far all seem to tell me âIt just worksâ˘â (Meteor Guide - Hot Code Push), but there doesnât seem to be anything about how the underlying mechanism actually works, fully, from end to end.
Every time I read it I get a bit confused, anxious and feel bad because it feels like itâs something I should already know:
Controlling compatibility version:
The compatibility version can be found in thecordovaCompatibilityVersionsattribute of the JSON file served atROOT_URL/__cordova/manifest.jsonduringmeteor run [ios/android].
You may want to override the compatibility version if you want hot code push to reach older apps that donât have the latest version of your native code from the app store. Letâs say youâre developing an iOS app, you have the plugin
cordova-plugin-camera@2.4.0, and your app has the compatibility version pictured above,3ed5b9318b2916b595f7721759ead4d708dfbd46. If you were to update to version2.4.1ofcordova-plugin-camera, your server would generate a new compatibility version and your usersâ apps would stop receiving hot code pushes. However, you can tell your server to use the old compatilibity version:
METEOR_CORDOVA_COMPAT_VERSION_IOS=3ed5b9318b2916b595f7721759ead4d708dfbd46 meteor run ios-device
# or
METEOR_CORDOVA_COMPAT_VERSION_IOS=3ed5b9318b2916b595f7721759ead4d708dfbd46 meteor build ../build --server=127.0.0.1:3000
⌠one moment please, I should what the what now?
How do I know my old compatibility version when Iâm building the new version of my app at the moment? Should I keep tabs after building each released version about the compatibility versions for ios + android? What if I didnât do it? And the version created locally with meteor run ios/android is the same as the one on my live server? What if I upload a new Build of my server? Is the compatibility version the same? Aah, I guess I pass in the previousâ versions version string to the new build using the (undocumented) environment variable?
â There just doesnât seem to be enough information about the whole process around / documented.
Q: What are all the other asset information (hashes) in __cordova/manifest.json in my App used for? Is it possible that the HCP would fail if any of those resources would change too? â Because that is the impression that I get, I have the feeling the HCP doesnât work more often than it does⌠(see eg. Git Issues: âCordova iOS HCP fails if you add a png to your projectâ)
There is also something about the âblacklistingâ of versions. Mmh, iâd rather notâŚ? I have the feeling this mostly serves to break the upgrade process because the webapp - / HCP - plugin things we have an incompatible update for some reason - are you sure this isnât connected to the asset manifest above, dear Guide? (It says a new Versions gets blacklistet if it fails to start multiple times).
Q: How do I control the process / fix my app after the fact (after a new version has shipped / I donât know all my hashes?) so my clients get the newest version when I want them to?
In another Github Issue (Hot Code Push broken on iOS) we get a hint of an interesting possible solution:
SET METEOR_CORDOVA_COMPAT_VERSION_ANDROID=v0001
SET METEOR_CORDOVA_COMPAT_VERSION_IOS=v0001
meteor build / deploy (...)
- setting this before both the mobile clients + the server build. (Where is this documented please?!)
Sounds great! 
This way we could control the updates ourselves⌠or could we?
Q: Is this really all there is to it? Can we be 100% sure that the HCP will always run if we build a new version of the server whilst keeping the METEOR_CORDOVA_COMPAT_VERSION_* the same? Because I have the feeling there might be more issues / things lurking underneath the surface?
Next question: In the client I can see some information about autoupdate versions:
⌠but what does it all mean? What is a versionNotRefreshable? Whatâs versionRefreshable? And what is version? And why are they all different? How can I use this? Where is my SET METEOR_CORDOVA_COMPAT_VERSION_ANDROID=v0001 I so painstakingly tried to set?
On the client:
There is this cool plugin that lets me hold back / control the update process a bit:
https://github.com/jamielob/reloader
â But there isnât anything about âIs my HCP foobarâdâ or âFxxx it do it anyway / try again from the start of the processâ or anything which might help me salvage an app once it crossed the no-HCP-Rubicon. Which kind of sucks, because then I can start building + deploying a new app, upload it, fix some issue with a new deprecated this-or-that apple figured out, build once more, wait for Testflight to gimme a green light, create a new release & wait about 2 1/2 days until my clients get the much-needed hotfixâŚ
- whatâs with Meteorsâ own reload package? â I think it mostly takes care of keeping Session variables around and doesnât seem to be too related to the discussion I think.
Q: Can I recover somewhere from the client if anything goes wrong here?
So, this was a lot of rambling. This is my knowledge to this point. I think itâs not enough and it feels bad. I want to be able to tell my clients when the update will go live & be reasonably sure that itâll actually work this time.
I want to know whatâs happening under the hood and be able to fix simple issues using either the server or the client by either pushing a new version with some additional data or let the client retry the HCP reload now and then.
PLEASE add all you knowledge to get me on the road to HCP nirvana. Iâm happy if it turns out Iâm the only one not knowing where this is all written up in the docsâŚ
I think this is a great and valuable feature to have, if used responsibly, but for that to work we need to be able to rely on it.
If there isnât a lot of progress here Iâll start source diving, but I hope to get some initial pointers here at least. I think this is a topic of broader interest.
Thanks & bye!
â Some healthy snacks for you if you read this far!
