F-Droid should prioritize the variant with the highest build number when app is available in multiple repos
Note: Perhaps somewhat related to #2247 and #1887 (closed)
I erroneously began discussion in this in fdroiddata#2456 (closed) and want to begin anew here. I want to suggest improvements for the F-Droid client deciding which of multiple versions / variants it should suggest / install.
The IzzyOnDroid F-Droid repository adds tremendous value for applications that don't appear in (or have their own) F-Droid repository. However, Session does have its own F-Droid repository at:
with the files hosted at:
https://github.com/oxen-io/session-fdroid
I had Session 1.14.1 (2935), a "universal" .apk containing all of the architecture-specific code for the four most common Android platforms: x86_64, arm64-v8a, x86, and armeabi-v7a. A recent sync of the repositories I have installed showed a release of version 1.15.1. The IzzyOnDroid F-Droid Repo offered 1.15.1 (2961), the armeabi-v7a variant, while the Session F-Droid repository had 1.15.1 (2965), again a universal .apk containing all four architectures. The F-Droid client "suggested" 1.15.1 (2961), and, indeed, I installed that .apk, before reliazing that I wanted to keep the arm64-v8a variant. Even after installing 1.15.1 (2965), F-Droid still "suggests" 1.15.1 (2961), which would represent a downgrade from arm64-v8a to armeabi-v7a.
I believe that when selecting among possible variants:
- F-Droid should prioritize arm64-v8a over armeabi-v7a and x86_64 over x86.
- F-Droid should prioritize the variant with the highest build number (2965 over 2961).
- F-Droid should prioritize keeping (assuming the signatures match, which they do in this case) installing an upgrade from the same repository over installing an upgrade from a different repository.
Instead, the client suggested (and continues to suggest) a variant that meets none of those criteria.