api/v1/packages can return versions that not in the F-Droid repo.
At the time of writing, https://f-droid.org/api/v1/packages/app.pachli returns the following (formatted for presentation here):
{
"packageName": "app.pachli",
"suggestedVersionCode": 15,
"packages": [
{
"versionName":"2.4.0",
"versionCode": 13
},
{
"versionName": "2.3.0",
"versionCode": 12
},
{
"versionName": "2.2.0",
"versionCode": 11
}
]
}
Notice that the suggestedVersionCode
is not in the list of packages
-- this is because there was a connection failure connecting to the git repo the last time F-Droid tried to build this package.
This means versionCode 15 is not in the F-Droid repo (at the time of writing, it might be by the time you read this issue).
https://f-droid.org/en/docs/All_our_APIs/ says that this API lists "the published and suggested versions".
a. It's not clear that "published and suggested versions" in this context means "published by the application author". I think a more reasonable expectation of that text is "published in the F-Droid repo, and suggested for the user to install". Especially when the property is named suggestedVersionCode
.
Issue 1: Please update the docs to include a description of the semantics of the different properties in the response, including making it clear that the suggestedVersionCode
may not be available in the F-Droid repo.
b. It's not clear how a client, using this API, can determine which version (if any) is available in the F-Droid repository.
In the Matrix chat there was a suggestion to fetch and parse index-v2.json to get this data. That's a 38MB file; it doesn't seem reasonable to expect an app to periodically fetch and parse 38MB (and growing) of JSON just to determine whether the F-Droid repo contains a newer version of the app.
Is the packages
property guaranteed to only include versions that are actually in the F-Droid repo? In the JSON above all the packages
entries are published, it's only the suggestionVersionCode
that isn't.
If it is then I can change the update-check code to look for the highest version code in the packages
list, and ignore suggestedVersionCode
.
Issue 2:
If the packages
property is guaranteed to include versions that are in the F-Droid repo please update the documentation to make that clear.
If the packages
property is not guaranteed to include versions that are in the F-Droid repo then (a) please update the documentation to make that clear, and (b) please consider introducing an API call (or parameter to the existing API call) that restricts the results to only include versions that the user can install with the F-Droid client.
I looked at shields.io, since that's listed as a user of the API, and they (https://github.com/badges/shields/blob/master/services/f-droid/f-droid.service.js) seem to start with the suggestedVersionCode
, falling back to the highest version code in the packages
list if the suggestedVersionCode
is not in the packagesList
. That allows for the possibility that the suggestedVersionCode
may not be the highest version in the packages
list.
Is that the correct algorithm to use? If it is, updating the documentation to be explicit about that would also be very helpful.
Thanks.
[To forestall "The F-Droid client checks and prompts the user for updates, you don't need to", either this is not the case, or users disable this feature or the F-Droid client notifications about out-of-date apps. I had a long-tail of users using old Pachli versions, that long-tail started to diminish significantly once I added a periodic check in-app to see if there was a newer version of the app in the F-Droid repo]