Last tags lack releases & APKs

[IzzySoft]

The last tags (1.4.8 and 1.4.9) have no corresponding release and no APKs attached – so the app cannot be updated in my repo. Would you consider adding those – or do you rather wish I shall "unlist", now that Saisoncalendar is long available at F-Droid?

[Flunzmas]

Pinging @matzebond for this one, since he initiated the latest releases (I unfortunately don't have the time currently to work on this).

[matzebond]

On my todo list is setting up a github action to automatically build the apk.
Note: The apk signature will change

@Flunzmas do you mind converting this repo to an organization so i can experiment with the CI/CD

[IzzySoft]

Note: The apk signature will change

Uh? Any urgent reason for that? This kind of change should always be avoided unless really, really needed (e.g. original signing keys got lost/compromised). It not only means users have to uninstall & reinstall, but also that due to lack of update notifications (an incompatible update will be ignored) they are unaware of that.

[Flunzmas]

On my todo list is setting up a github action to automatically build the apk. Note: The apk signature will change

@Flunzmas do you mind converting this repo to an organization so i can experiment with the CI/CD

We can definitely move this to an orgainzation, but I also think that we have to keep the APK signature... it will cause all sorts of awkward issues otherwise.

[matzebond]

I was unsure about the about of work you can put into this issue. So I assumed I would have to generate a new signature but if you are interested we can probably set up a github secret to allow CI/CD with the correct signature.

[matzebond]

The CI is now working :)
I created the releases and attached the corresponding apks which have the same signature as the previous build.

[IzzySoft]

Good to read, thanks! Will the per-ABI builds follow? The last release wasn't picked up as my updater was just looking for /armeabi-v7a/i. As 23M are in the "acceptable range", it's now your decision what should be served via my repo:

• a single APK of the current "fat build" (i.e. the latest version only) – then I just need to adjust my config
• the last two versions of the ARMv7 build – then you'd need to provide its APK (as last done with v1.4.7)

While the answer might look easy ("why, if it fits, take the full one"), the problem is not obvious – so let me tell you: the "fat build" has versionCode: 42 for v1.4.7. Flutter prefixes ABI-specific builds – and don't ask me why, especially not for why ARMv7 gets the highest prefix: for v1.4.7 it comes as versionCode: 4042. Thus switching to the "fat build" will leave all current users in the dark. Not only will they get no update notification, but Android will refuse to accept the update as it considers it a (forbidden) downgrade because 43 < 4042.

TL;DR: switching to the "fat build" means each current user must uninstall and reinstall. I leave the decision to you.

[Flunzmas]

Since you already provide a specific ABI release, we will stick with that and also include building the per-ABI versions in our CI. Should happen today or tomorrow :)

[IzzySoft]

Thanks! My updater checker should find it automatically then (if you stick to the naming schema used in the past). Just drop me a note to check and make sure if you want 😃

[Flunzmas]

Then here's your note: The files have been included in the releases and our CI will ensure this happens automatically in the future 😊

[IzzySoft]

I've just checked, things look pretty much messed up:

• my repo had the arm64 APK, prefixed (as mentioned above) with a 40
• my config said to pull the armv7, which now has prefix 10
• the arm64 available at the current tag has prefix 20, the fat one has no prefix
• the 40 prefix now sits on the x86 build

So regardless which of the APKs I pull now, none of the current users will get any update. Options:

• we ignore that and I continue sticking to armv7
• we ignore that and switch to fat as it's all a mess anyway
• you check if the prefixes can be arranged in a way to fit the build I shall serve (either armv7 or arm64)

Until you decided, I'll keep things as they are. No harm done: nobody will receive any updates anyway, and first-time installers of the armv7 (prefix 10) will receive updates if the prefixes are rearranged, no matter how; for those om arm64 nothing changes anyway.

[matzebond]

According to https://developer.android.com/studio/build/configure-apk-splits#configure-APK-versions changing the versionCode per abi is the "correct" behavior. Something along the lines of

ext.abiCodes = ['armeabi-v7a':?, arm64:4, x86:?, x86_64:?] // old?
ext.abiCodes = ['armeabi-v7a':1, arm64:2, x86:?, x86_64:4] // now
...
output.versionCodeOverride =  baseAbiVersionCode * 1000 + variant.versionCode

you check if the prefixes can be arranged in a way to fit the build I shall serve (either armv7 or arm64)

My first attempt with to change the prefix mapping was no successful.

Maybe the mapping has changed due to updating gradle or because its build in the CI.
Reverting the gradle version (if that is the issue) seem too hacky and if its the CI i

I suggest we "stick to armv7" and hope current users will eventually deinstall an reinstall the app 🙃
@IzzySoft Do you have any stats on how often the v.1.4.7 was downloaded?

In flutter/flutter#39817 it was mentioned that

The APKs generated from an app bundle will have the same version.

So at least for the google play release this will not be an issue.

[IzzySoft]

I suggest we "stick to armv7"

Fine with me – but shouldn't we then apply the '4' again to that one to make sure all existing users get their updates automatically?

Do you have any stats on how often the v.1.4.7 was downloaded?

Not really, but I can try to fake some. According to my logrotate intervals (last one gets rotated to /dev/null, so no eternal stats):

• today: 2 times
• 2022-02-13 to 2022-02-19: 15 times
• 2022-02-06 to 2022-02-12: 15 times
• 2022-01-30 to 2022-02-11: 20 times
• 2022-01-23 to 2022-01-29: 20 times

So the closer we get to its release date, the higher the number of downloads. What a coincidence that the last log interval above starts with the release date 🤣 And thanks to the messed-up versionCode, v1.4.7 is still shown as being the newest one (higher versionCode), and thus will still be the one installed by default.

The APKs generated from an app bundle will have the same version.

Yeah, that's an entirely different thing.

[matzebond]

I just pushed the code to fix/revert the versionCode adjustment. Now the versionCodes are

arm64-v8a   versionCode orig 44 override with 4044
armeabi-v7a versionCode orig 44 override with 3044
x86_64      versionCode orig 44 override with 2044

my repo had the arm64 APK, prefixed (as mentioned above) with a 40
my config said to pull the armv7, which now has prefix 10

Did you change the the ABI variant that is provided by your repo?
Let me know if the version codes above are still wrong.
We will make a bigger release soonish and by then everybody will hopefully be able to upgrade again :-)

[IzzySoft]

I've kept it to the armeabi variant here. But as we started in my repo with the 40xx version codes, I'd have to switch to arm64 so folks get updates (provided their devices support arm64). I never understood why 32bit got the higher number anyway: your new ordering sounds much saner. So shall I switch to arm64 then?

[matzebond]

If it always has been armeabi in your repo then let us keep it that way and I will change the version code for armeabi to 40xx

[IzzySoft]

It has not, I made a mistake with the initial listing and accidentally had put the x86 there (which at the time had the 40xx version codes). Well, that said, those users cannot upgrade to any ARM version anyway – so it wouldn't matter much, would it? I usually pick the armeabi version as that covers most devices (even most arm64 devices can use that, while the opposite is not true). So just let me know which one I should pick; keeping the current prefixes would allow users switching from a 32bit ARM device to a 64bit one to simply upgrade to the 64bit as well (though probably not via my repo then).

[IzzySoft]

@matzebond id we decide? Because currently my updater pulls the APK from the last release each day just to throw it away, as its versionCode (1044) is lower than the old one (4042). Guess I'll simply drop the 4042 now as it's the x86 one we'll not pick anyway. So whatever you choose: VC will be higher than 1044 in any case. I'll continue to pick armeabi-v7a until you tell me otherwise – with what you wrote above, that would then be 30xx and even switching to arm64 will result in a higher VC, namely 40xx, so no problems.

[matzebond]

Yes keep it at armeabi-v7a. The next release v1.5 code 45 will have armeabi-v7a as 4045 and should be ready in the next week.

[IzzySoft]

Urn, you switched the codes again? Last word was

arm64-v8a   versionCode orig 44 override with 4044
armeabi-v7a versionCode orig 44 override with 3044
x86_64      versionCode orig 44 override with 2044

So I'd expected 3045 for the armeabi-v7a (so updating to arm64 is possible; updating from the previous 40xx x86 build to arm is unlikely anyway, so for my repo we can ignore that one – which btw I've already deleted). Up to you of course; the current one in my repo is 10xx, so any of the 4 would count as update. I just want to prevent issues if one day we decide to go arm64, when those devices are the majority.

Guess I've messed up with my comment from 9 days ago – please ignore the update-part from there, there are no updates from x86 to arm 🤣

[matzebond]

Uf seem like several miss understandings and I am a little lost but since

arm64-v8a   versionCode orig 44 override with 4044
armeabi-v7a versionCode orig 44 override with 3044
x86_64      versionCode orig 44 override with 2044

looks good to you, I will keep it that way.

[IzzySoft]

Thanks a lot! Then we should be all set 😃 The next update will be picked automatically, its 30xx is greater than the current 10xx, so updates will keep flowing in and "outdates" be purged in the right order. All fine until the next switching 🤣