Im Gegensatz zum Google Play Store haben App-Entwickler im F-Droid Store praktisch keine Kontrolle / keinen Einfluss über den Release- und Update-Prozess ihrer App. Vielmehr sind sog. Maintainer für das Einstellen der Releases und Updates der Apps in den F-Droid Store verantwortlich. Falls der Maintainer also nachlässig ist oder gerade »verhindert« ist, kann dies zur Folge haben, dass im schlimmsten Falle auf bekanntgewordene Sicherheitslücken in Apps nicht zeitnah reagiert wird, obwohl der Entwickler diese bereits geschlossen hat.
Translation: Developers don’t control the updates at F-Droid, these happens by so called maintainers. If the maintainer does not do its job good or does not have time, then security vulnerabilities are not fixed fast even if the developer fixed them.
I already discussed with him about the auto update process. However, he said that there are cases where f-droid builds Apps without support of the developer and then the developer does not have got control about new releases.
My question now: Which Apps (not specific, but how can one see if one App is such one) have got delayed updates and why?
One way would be to compare the version number of the F-Droid release with other sources, e.g. with the help of ApkTrack. If an app is behind with updates it could also mean the F-Droid version won’t receive any updates at all anymore because upstream is no longer free software, like with these 104 apps.
Apps are published when an update/build/sign cycle ends, and that time can’t be predicted, due to various factors (number of apps, per app build time, server issues etc). If the dev just says “the bug is fixed, I’ve tagged the repo, why don’t you publish?!?!?!?!” that’s kinda unjustified if not nasty.
@Licaon_Kter I know that the processes take some time. Let me ask differently: When are there manual (not automated) actions (and what are the causes) and how can I “see” which Apps need often manual work?
Apps without autoupdate have this issue, either the dev opens a MergeRequest (if they care), or users raise up issues about a new version being out, and this delays it more or less (compared to autoupdate) since one of us needs to build test first before merging.