An application's versions live in data/versions.json, keyed by a long integer version and valued with the human one:

{
    "10000": "1.0.0",
    "10001": "1.0.1",
    "10002": "1.0.2"
}

Uploading the same version number is silently a no-op

Invision Community compares the long version in the uploaded file against the installed one. If it is not higher, the upload is accepted and nothing happens. No error, no warning, no changed files.

This is the single most wasteful mistake in application development, because the symptom is "my fix did not work" and the instinct is to go back and debug code that was never installed. If you have built a tar and it has left your machine, the next change gets a new version. Rebuilding the same number for a quick fix does not work.

Check what is actually installed before assuming otherwise:

SELECT app_directory, app_version, app_long_version
FROM core_applications
WHERE app_directory LIKE 'myapp%';

Every version needs an upgrade step

A new key in versions.json needs a matching setup/upg_<long>/ directory, at minimum a data.json declaring which upgrade steps to run:

{
    "id": 10002,
    "name": "1.0.2",
    "steps": {
        "queries": false,
        "lang": true,
        "settings": false,
        "tasks": false,
        "modules": false,
        "widgets": false,
        ...
    },
    "forceMainUpgrader": false
}

Set lang to true whenever you added or changed language strings, settings when you added settings, tasks when you added a scheduled task, widgets when a block changed. Leaving them all false means the code ships but its supporting data does not, which produces an application that installs cleanly and then shows raw language keys.

Language changes need a lang.json too

{
    "normal": {
        "added":   [ "myapp_new_setting", "myapp_new_setting_desc" ],
        "edited":  [],
        "removed": []
    },
    "js": { "added": [], "edited": [], "removed": [] }
}

Verify the built file rather than trusting the build

A tar named myapp-1.0.2.tar can easily contain 1.0.1 — the filename is whatever you typed, the contents are whatever was on disk. Check the two agree before uploading:

tar -xOf dist/myapp-1.0.2.tar data/versions.json
tar -xOf dist/myapp-1.0.2.tar --wildcards '*lang.xml' | grep -c 'key='

And check the dev/ directory did not get included, which happens easily and ships your working files to customers:

tar -tf dist/myapp-1.0.2.tar | grep -c '^myapp/dev/'   # should be 0

Verified against

Invision Community 5.0.19, by reading the application upgrade handling and by shipping applications through it.

Related: A malformed manifest silently disables your whole application, The core/Build extension in Invision Community 5, What you can and cannot test from the command line