versionCode for 1.1.7 wrong

[IzzySoft]

Unfortunately you forgot to increase versionCode for v1.1.7, so the corresponding APK still has the same as v1.1.6 and will thus be ignored for updates:

WARNING  repo/com.mubarak.mbcompass_7.apk already exists; ignoring update for com.mubarak.mbcompass, versionCode 7 already present.

Just to let you know so you can take care with v1.1.8 appropriately 😉

[MubarakNative]

Thanks for the detailed explanation. I realize now that I tagged and released v1.1.7 from a feature branch before merging to main, which caused the APK mismatch you pointed out.

Would it be okay if I:

Either delete and re-tag v1.1.7 after merging into main, then rebuild and re-upload the APK?

Or alternatively, bump to v1.1.8 with a new tag and updated versionCode, built properly from main?

Let me know which approach you prefer for your pipeline. I’d like to keep things clean and reproducible moving forward.

Thanks again for your time!

[licaon-kter]

Also APK built from the wrong commit? https://gitlab.com/fdroid/checkupdates-bot-fdroiddata/-/jobs/10421428117#L459

[MubarakNative]

What could be the possible fix

[licaon-kter]

Build from the Tagged commit but....if versionCode is wrong...fix it and retag and rebuild

[IzzySoft]

@licaon-kter how was it with "never replace what has already been distributed"? That tag was already processed e.g. by our builders, and thus would not be processed again when "replaced", hence leaving the RB shield down (as sha256 hashes of the APK files would not match).

bump to v1.1.8 with a new tag and updated versionCode, built properly from main?

@MubarakNative This would fit us all nicely, as it's the cleanest approach, thanks! Also for:

I’d like to keep things clean and reproducible moving forward.

🤗 Let me leave a link to our hints on reproducible builds for that, cannot hurt 😉

[licaon-kter]

How was that processed if the version was wrong?

[IzzySoft]

git clone && ./gradlew assembleRelease? Remember, at IzzyOnDroid RB checks and repo updates run on separate tracks. RB doesn't check what versionCode is set, unless it leads to a mismatch upstream vs. local. And some "minor mismatches" are auto-corrected by our builders' updaters (e.g. they automatically insert a git reset --soft to the embedded commit hash if that differs from the tagged commit – which then in 90% of the cases leads to a successful RB).

So unless an APK is technically "broken" (i.e. cannot be installed at all and thus should be removed), it should not be "replaced". The cleanest approach always is a "maintenance release". That way you also do not have to consider any "ifs" and "if-nots". Remove the APK if it was broken or had severe security issues, but provide the fix with a new release. Also gives full transparency.

[MubarakNative]

@IzzySoft v1.1.8 released!

[licaon-kter]

1.1.8 is ok 👍

[IzzySoft]

And RB. Went live at IzzyOnDroid with the last sync 14h ago already 😃

Btw, if you want to "show off" the RB status:

[<img src="https://shields.rbtlog.dev/simple/com.mubarak.mbcompass" alt="RB shield">](https://shields.rbtlog.dev/com.mubarak.mbcompass)

[MubarakNative]

Thank you, Izzy, for the guidance.