versionCode and releases

IzzySoft commented 2 years ago

It seems that since MkIIIv34, versionCode was never increased: it's still stating 90. As Android uses this to tell versions apart, new releases are never announced to the user.

Further, the current tag naming makes it hard to automatically fetch updates (I just noticed today that I missed quite a few of them, as MkIIIv34 compared against MkIV_dev20_release was interpreted as 34 > 20 and thus the new tag being ignored). Can you please clarify the difference between MkIII and MkIV? Looks like these are two "branches" released at the same time.

For fetching updates it would help enormously having tag names with clear versioning as well as corresponding versionName or versionCode (you could e.g. use prefixes as you currently seem to do: mkiii_<versionCode> and mkiv_<versionCode> would be great as that way you cannot forget increasing it either :wink:)

Thanks in advance!

Edit: I've now defined MkIIIv as prefix with my metadata, and that seems to do the trick for the automatic updates, but due to the unchanged versionCode they won't be brought to the users' attention (no update announcement).

green-green-avk commented 2 years ago

It seems, MkIIIv and MkIV-dev version prefixes are pretty good to represent both branches now. I'm not planning to remove the -dev suffix soon. I hope, you have a way to publish two applications with the same ID as it makes interchangeability between Wayland and stable (master branch) editions much simpler.

IzzySoft commented 2 years ago

No, applicationId is unique per app. While using the same applicationId would make cross-updates easier, it would also make accidental cross-updates easier – as Android wouldn't know they are different apps. So here's what would happen with automatic updates then: "you have com.foobar installed with versionCode: 5? Oh, there's a com.foobar with versionCode: 6, let me update that for you…"

With different tag naming patterns, I can tell my updater which one to pick, so users of my repo wouldn't receive "accidental cross-updates". But I could not serve both apps simultaneously if they share the identical applicationId.

green-green-avk commented 2 years ago

I see. 1) Same applicationId - In this case, it's better to prefer MkIIIv branch. (I wonder why the FDroid infrastructure still lack of some feature to switch between branches with the same applicationId.) 2) Same versionCode - What about downgrade? (I also wonder why the FDroid infrastructure still does not provide some alternative versioning scheme to trick the Android to downgrade seamlessly (without wiping the app data).)

IzzySoft commented 2 years ago

Well, many people wonder many things. If F-Droid provided those features, they'd wonder the other way around – and complain about degraded security :laughing:

Why a downgrade to a lower versionCode is no longer possible (it once was) you must ask those who made that rule. Probably because that could break things (imagine an upgrade changed the structures of your local SQLite database. How'd you expect the older version to deal with that?). Plus honestly, how often have you needed to downgrade? The very few times I had, I simply uninstalled and restored from backup.

So I'll stick with the MkIIIv branch/flavor then for my repo. How can we ensure I don't pick an APK from the other one accidentally? Please remember that possibility should you one day decide to drop the suffix. And will you consider increasing versionCode?

green-green-avk commented 2 years ago

...imagine an upgrade changed the structures of your local SQLite database...

Imagine, you have a pretty large amount of data. I see no reason to copy it forward and backward for nothing. Why Google does not simply provide some kind of an opt-out option in case I can deal with forward compatibility by myself? That's weird.

Plus honestly, how often have you needed to downgrade?...

It could be pretty real:

Android OS images cannot provide you with the exact details of real devices behavior;
Android device farms are usually have no relatively old devices.

So there is no way to test an app thoroughly enough. See issue #22 for example. This particular application MUST have a way for quick downgrade.

If you really need something with versionCode semantics, It's possible to use some other place in APK for it. I'll do it a bit later.

So I'll stick with the MkIIIv branch/flavor then for my repo...

You can stick with

any releases on the master branch or
the release names match ^Mk([IVXLCDM]+)v([0-9]+)$ where $1 - (latin) major part; $2 - minor part of the version.

These will be always correct.

IzzySoft commented 2 years ago

Why Google does …

I've stopped asking that question long ago. See e.g. Your app is not compliant with Google Play Policies: A story from hell. And yes, I'd also prefer some adb install -r --force for such cases – but we don't have it.

the release names match ^Mk([IVXLCDM]+)v([0-9]+)$

As pointed out above, I told my updater to stick to MkIIIv<versionName> – but taking a closer look, that won't fetch any updates at all as the version name is MkIIIv\d+. So not only users won't receive update notifications as versionCode isn't increased – my updater does not even have a chance fetching any updates (without accidentally fetching the wrong ones). And no, I cannot implement another exception handling just for a single app. The last one currently in my repo is a v53 dating 2021-05-02 (which is probably the date the first release with that versionCode was made, as the file date correctly states 2022-06-02). This is a mess. And I cannot even go by the suffix (you're appending a _release to ALL tag names). And I cannot go by the file names either, as those are the same for MkIII and MkIV.

So with the current setup, I can either fetch no updates at all – or run the risk fetching the wrong ones. I can only specify exactly one RegEx on the tag name – and that then must include a place holder for either versionName or versionCode (so I don't have to download the APK everytime only to find out it's still the old one).

Oh? Looks like the version compare can deal with that, comparing MkIIIv53 (the last release in my repo) against 54_release (resulting from the mentioned RegEx), finding the latter being newer. Patrick did a great job providing me that rewrite :rofl: So it seems at least at that part we're good.

$ ./getRelease.php -vp green_green_avk.anotherterm.redist
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/releases'
green_green_avk.anotherterm.redist: checking tag 'MkIV_dev21_release'
green_green_avk.anotherterm.redist: checking tag 'MkIIIv54_release'
green_green_avk.anotherterm.redist: lastRelNo set to '54_release', checking for files
Upstream file date (2022-07-07 22:15) is newer than ours (2021-05-02 02:00).
green_green_avk.anotherterm.redist: returning ['54_release','https://github.com/green-green-avk/AnotherTerm/releases/download/MkIIIv54_release/app-redist-release.apk']
green_green_avk.anotherterm.redist: MkIIIv53/54_release, GH https://github.com/green-green-avk/AnotherTerm/releases: https://github.com/green-green-avk/AnotherTerm/releases/download/MkIIIv54_release/app-redist-release.apk
- Grabbing update for green_green_avk.anotherterm.redist: OK
Binary files green_green_avk.anotherterm.redist_90.apk and green_green_avk.anotherterm.redist_54_release.apk differ
green_green_avk.anotherterm.redist_90.apk already exists, quarantining before replacing it with update
- Checking 'green_green_avk.anotherterm.redist_90.apk' for libraries and malware …
..

Still, users won't receive any update notifications as versionCode again remained unchanged.

green-green-avk commented 2 years ago

...And no, I cannot implement another exception handling just for a single app...

It seems, the only thing you need to do is to add to your updater an ability to specify a short lambda function on per app basis to parse tags... It will be a general solution.

In this case the lambda will look that simple (JavaScript):

(tag) => {
    const parseRoman = (input) => {
        const nn = { I: 1, V: 5, X: 10, L: 50, C: 100, D: 500, M: 1000 };
        return [...input.toUpperCase()].reduce((pv, cv, ci, a) =>
            nn[a[ci + 1]] > nn[cv] ? pv - nn[cv] : pv + nn[cv], 0);
    };
    const m = /^Mk([IVXLCDM]+)v([0-9]+)_release$/.exec(tag);
    return (m ? (parseRoman(m[1]) << 16) + parseInt(m[2], 10) : null) || null;
}

If you provide me with a link to your code, I could do it for you.

IzzySoft commented 2 years ago

Thanks! But making the code more complex for a single app is not what I'd go for (especially when it turns out that part does work – but the code update would break it for the 800+ other apps in the repo :wink:) No, the only thing missing now is the update notification for the users of the app. Which cannot be fixed unless the versionCode will be increased.

IzzySoft commented 2 years ago

Just picking up the question again, as today my updater once more informed me about there being a problem with versionCode and I had to search why (cannot remember details for all the apps, apologies): Will you increase versionCode properly with the MKIII redist APK at least, which is the one I pick? Those users who want a not-changing versionCode could come to your releases section and pick another one manually, as they need to update manually anyway. But those who prefer update notifications and maybe even automated updates could still receive them via my repo then.

IzzySoft commented 1 year ago

It doesn't make much sense to put an app in a repo if it doesn't offer updates:

as versionCode is never increased, there won't be any update notifications
even if the user checks manually, there won't be any "update" button (for the same reason); and even though F-Droid offers "downgrades", that possibility doesn't exist either as there are no "previous versions" due to all of them being "the same"
so all left is to manually download the APK file and side-load it – which is not how an app-repo works or what it is intended for; essentially concerning this specific app it doesn't make much difference if it's in the repo or not, apart for initially discovery and install

So @green-green-avk may I suggest a last time to have an APK with proper versioning? If you prefer it without, maybe just attach it as a separate APK, and mark it with "proper versioning for UPGRADABILITY" :speak_no_evil:

green-green-avk commented 1 year ago

Sorry for the late response.

Ok. I'll add a new fdroid flavor for both branches in the next release (in case you prefer MkIV-dev once).

IzzySoft commented 1 year ago

Thanks a lot! Please let me know when it's there so I can adjust my updater accordingly to pull the right files.

green-green-avk commented 1 year ago

Ready.

From now on:

*-versioned-* flavors have the standard versioning.
*-downgradable-* flavors uses the releaseVersionCode application metadata bundle field. https://github.com/green-green-avk/AnotherTerm/blob/f9806e5a5bdb02255b6ab63c3ffe80ad30773fb2/app/src/downgradable/AndroidManifest.xml#L1-L10

IzzySoft commented 1 year ago

Thanks a lot! :star_struck: Adjusted the config here and triggered an update check: updater no longer complains, users will receive update notifications – wonderful!

$ iod repo get green_green_avk.anotherterm.redist
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/releases'
green_green_avk.anotherterm.redist: checking tag 'MkIV_dev41_release'
green_green_avk.anotherterm.redist: checking tag 'MkIIIv74_release'
green_green_avk.anotherterm.redist: lastRelNo set to '74_release', checking for files
Upstream file date (2023-03-08 04:39) is newer than ours (2021-05-02 02:00).
green_green_avk.anotherterm.redist: returning ['74_release','https://github.com/green-green-avk/AnotherTerm/releases/download/MkIIIv74_release/app-redist-versioned-release.apk']
green_green_avk.anotherterm.redist: MkIIIv73/74_release, https://github.com/green-green-avk/AnotherTerm/releases: https://github.com/green-green-avk/AnotherTerm/releases/download/MkIIIv74_release/app-redist-versioned-release.apk
- Grabbing update for green_green_avk.anotherterm.redist: OK
- Checking 'repo/green_green_avk.anotherterm.redist_133.apk' for libraries and malware …
green_green_avk.anotherterm.redist: check if repo contains FUNDING.yml
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/.github'
green_green_avk.anotherterm.redist: Github reports "Not Found" for https://api.github.com/repos/green-green-avk/AnotherTerm/contents/.github
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/'
green_green_avk.anotherterm.redist: no FUNDING.yml detected.
green_green_avk.anotherterm.redist: calling 'getFastlaneMeta(github,[host:github.com,owner:green-green-avk,repo:AnotherTerm,path:/fastlane/metadata/android])'
green_green_avk.anotherterm.redist: FastlaneFeatures shortdesc,fulldescMD,icon
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/fastlane%2Fmetadata%2Fandroid'
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/fastlane%2Fmetadata%2Fandroid%2Fde'
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/fastlane%2Fmetadata%2Fandroid%2Fen-US'
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/fastlane%2Fmetadata%2Fandroid%2Fen-US%2Fimages'
green_green_avk.anotherterm.redist: checking locale 'de'
green_green_avk.anotherterm.redist: checking locale 'en-US'

PS: If you want to add the link next to the PlayStore one: https://apt.izzysoft.de/packages/green_green_avk.anotherterm.redist/ (you could also pick a badge for that if you wish).

green-green-avk / AnotherTerm

versionCode and releases #30