An OS is very different from an individual project. Typically, with an OS, you already have an installation media that is fairly large. From a bandwidth perspective, it often makes a lot of sense to install from that media and update the few programs that have changed rather than download a new installation media. This has no relation to the distribution of an out-of-date version of an application from the main webpage of an open source project. Firefox doesn’t do this. LibreOffice doesn’t do this. Nobody else in the entire world does this.
Debating these points does not get us closer to an actual solution.
My recommendation is that every stable release of F-Droid should automatically be the one that is downloaded from the website for new installs. If it isn’t good enough for a new install, it should not be released as stable. If there are problems, they should be addressed in the process by which alpha/beta/release candidates are evaluated before they are allowed to become stable.
3 Likes
And the question remains: who does that additional testing?
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.
1 Like
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.
How would you tackle Many never-installed apps listed in 'Installed Apps' (#1433) · Issues · F-Droid / Client · GitLab exactly?
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.
2 Likes
How would you tackle https://gitlab.com/fdroid/fdroidclient/issues/1433 exactly?
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.
1 Like
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.
2 Likes
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.
There is no difference
The difference is timing. After a few days, I might be concerned about permissions escalation…
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.
So, what exactly do you propose besides debating the facts surrounding the problem and discussing the merits of proposed solutions?
My experience is that when people no longer want to discuss the facts it is because they don’t like the solutions the facts point to.
1 Like
Listen to Hans, or convince him to redefine “stable.” My take is they already feel overloaded.