There is no “additional” testing. A bug that presents itself only on install but not on upgrade will not be device specific. If you are making changes to code that could create this type of bug, like the SQLite database creation code, you should test installing on at least one device. This is not “additional” testing. This is the bare minimum testing that should be required before any proposed updated is released as stable.
Therefore, the designation of a new release as stable should be sufficient to make that release the one that is distributed on the website.
My guess is that you are assuming that fdroidclient is developed via the
process you use. I’m guessing it is not. I generally work by limiting
changes to specific areas for each release, that means that all aspects
of the app do not need to be tested before each release. That saves a
lot of dev and testing time. This is a common dev workflow for doing
things efficiently.
Of course, a complete, automated test suite across every device we
support would be welcome. That does not currently exist.
Regardless, the point still stands that there is no conceivable scenario where F-Droid should be considered stable for upgrades but not for new installs. Every other open source project in the world, with every sort of development process (some much more complicated than F-Droid), has been able to figure this out.
Your argument seems to come down to, “We don’t do any testing of F-Droid before we release it as stable and recommend upgrades in the app. Rather, only after that point do we start testing to make sure it works. When we have finished the testing that everyone else does before they move a release candidate to stable, then we finally put our ‘stable’ version on the website.” I have a hard time believing that this describes the process as it actually happens, but if it does, then you need to fix it.
For my app I always do the tests on several emulators (phone, tablet, tv):
make a fresh install
make an update from previous version
make an update from a very old version (all new updates will be installed)
Works well for me
The problem with F-Droid is, I think, there are too much preferences with wifi, img download, auto refresh, network dependencies, F-Droid website dependencies, several repos… it becomes a nightmare to detect problems and reproduce them.
What I would do is to reduce the parameters to minimum to always have the same initial settings.
After installation, the users can change them.
It would be awesome if we finally could find a solution for this. Like @sorenstoutner wrote, its really no help to the users. I really have never seen any usecase, not even here in the forum, where people wrote ‘i am happy that i have been pushed to an outdated version before and had to update the app again at its first start’. It would make sense if there were many people who have issues when they would always get the most recent version by default. But there are none such users to my knowledge.
I really dont get the understandings for the benefits why the users should install an outdated F-Droid version first. There is no practical usecase that requires this behavior.
This is a good example of an intermittent issue that is difficult to catch in testing, especially on an emulator (because one doesn’t often rotate an emulator while a process is running). But it isn’t a good example of an issue that affects this topic. Because users who installed an outdated version of F-Droid from the website and then updated to the current version inside the app would experience this bug just as frequently as users who installed a current version from the website.
Which is my whole point. You are not solving any problem that should occur in the real world by deploying old versions from the website once they have been marked as stable releases in the app.
A small thing maybe, but f-droid needs “advanced” permission to install “unknown” apps. By quickly doing an f-droid update after f-droid download and install, it is sure to be given that permission by the user before trying to install other apps using f-droid.
It will automatically request that permission the first time it installs anything. There is no difference between the first thing it installs being an F-Droid update or any other app as far as this dialog is concerned.
It only asks for the permission immediately after you click on the button telling F-Droid to install an app. I would assume that most users would not be concerned about Android asking them if it is OK for F-Droid to install an app if they have just requested that F-Droid do so.
I don’t claim to know what most users prefer. I agree the quick update-after-install is not the same as most apps, but f-droid has a very different purpose than most apps. So a difference seems OK to me, if not ideal. We can go round and round forever, but they’ve told you what is needed - volunteers for testing. So volunteer or let’s stfu already about generalities.
There seems to be some confusion that fixing this problem would require additional testing. Such is not the case. No additional testing is required.
If an F-Droid release is ready to be marked as CurrentVersion in the manifest file, it is ready to be deployed through the website. If it is not ready to be deployed as the stable version, then it should remain an alpha or beta in the manifest file forever.
As such, it is a very simple fix that requires no extra work except for uploading a file to the website when it graduates from beta to stable.
I would agree with you that the entire F-Droid project is understaffed, and that Hans most likely does feel overloaded.
I have come to the conclusion quite a while ago in this thread that the powers that be are not going to make any changes to this workflow anytime in the near future.
The proposed solution that I have made requires no additional work. Thus, point number 1 regarding available manpower doesn’t apply to this situation.
I feel fairly confident that at some future point the powers that be at F-Droid will have a change of heart regarding this issue. The reason why I feel that way is because there is zero security or stability benefit to the current release process, the change requires no additional effort (just a change in attitude), and it would improve the experience for new users of F-Droid.
I do clearly see that in relation to all the other problems F-Droid faces this is rather minor. So, I am content to wait until the day that someone else convinces them to make what I consider to be the obvious choice.
I’m a relative noob to fdroid, but I’ve always been aware of it and used it to install some Foss must-have apps.
I’ve always wondered why the client updated every time I install it fresh. And I’ve always installed the updated client assuming it is pushed as a stable and most secure version.
Now I see the predicament.
And sympathise as you guys provide a marvellous and idealistic service, helping keep Foss alive in principle and in reality.
Can I suggest marking any rc candidates pushed on the client updater with the request that people report issues directly through an easy to see "report fdroid client bugs’ form; along with an opt out. The form should display a list of top ten (or so) known bugs that allows a user to tick “'this is my issue” which feeds somewhere that the devs can see priority issues; or click an “other issues” button which brings then to the support forums or gitlab; or better yet, presents a template similar to gitlabs issue tracker and it feeds to a private or open section of the support forum on a guest (maybe client id linked with permission) account -and have trusted forum users tag and collate each reported issue as known and merged, new, insufficient info, etc. Try to crowd source your bug collation.
Sorry if that idea doesn’t help. But I reckon you have a lot of good will out there given the nature of the fdroid project. Crowd sourcing might be a valuable resource that could help. You could also reach out to forums such as this, XDA, github, gitlab, sourceforge for volunteers for a temporary period to help. And based on complaints or assessed performance (in terms of appropriate tagging, etc and ask them back for a further period until you establish a trusted core of mods/fdroid associates and scale as needed from there.
Im just musing. But it would expand the community and maybe help you guys concentrate on the client and infrastructure.
