Issue: The main website, https://f-droid.org/ , nearly always host an outdated F-Droid version. When you install F-Droid, then the first thing it pops up is the update for F-Droid itself.
This does not make any sense. Why should people waste their data line to download a apk twice? When you download once the apk from the F-Droid store, then this apk should be the most recent one.
Stability reasons, eg. not push new users to use the latest versions.
That also does not make sense for me. The users get at first start from F-Droid the message, that they should update to the latest F-Droid version. Then the normal user do so.
ALL F-Droid users are “pushed(to use your words)” to the latest F-Droid version by making this version “recommended”.
Of course i am not talking here to provide to the F-Droid users the alpha/beta versions that also does not get the recommended flag in F-Droid. I talk here that the version with the recommended flag should always be the version you download when you press the download button on the main site. Then you dont have to update F-Droid itself after the first start of F-Droid.
If you’d like to see this change, we welcome contributions. In this case, the biggest need is lots of testing of initial F-Droid installs on a wide variety of devices and Android versions.
@hans
Lets start that initiative. Alfa and testing clients, with debugging in it. I’d additionally gladly give away some user metrics to avoid having to explain why upgrading F-Droid from within F-Droid makes sense, right out of the box.
That and the undisclosed warning of third party apps that is sprung upon the user is not really all that good publicity.
If not using the client to upgrade the client right away, that sends the message of not upgrading right away. Especially not upgrading right away when there in an F-Droid upgrade is very Windows.
I can just see people loose confidence in what I spend time explaining as a good idea when that takes place. It isn’t like they don’t want to use it, but they feel like they need an admin to do so, is what I am thinking.
Like the Windows mentality of lets not touch anything, because things appear flaky.
Not upgrading right away, when there is an upgrade, sends the message of that being fine. When that upgrade is F-Droid itself, letting it sit there is very Windows-like.
Most of the time novice users therefore do end up on the latest client, only with an upgrade in between. They could uninstall, and roll back by installing the website version, but that seems unplausible (?)
@hans
But the app (F-Droid) is been already tested. That is why it get the “recommended” flag after its been named Alpha before.
Or did i misunderstood some of the F-Droid idea? Because like @kingu wrote “They could uninstall, and roll back by installing the website version, but that seems unplausible (?)”.
When a user REALLY needs an outdated version, then at the moment he have no clue out of the APK file naming what version he have installed (the file from the main site is just named https://f-droid.org/FDroid.apk ). He have to look in the APK itself but when he cant install it, he have to really know what he is doing.
When you do the change i talked about, then its simple to know what version you have. You just check in your download directory the date you have download the file. Then you go to F-Droid | F-Droid - Free and Open Source Android App Repository and check the release date. Done. You know what F-Droid APK version you have.
Example: You had download a F-Droid APK on 2018-09-25. You check F-Droid | F-Droid - Free and Open Source Android App Repository . You see it have to be F-Droid version 1.4 because 1.5 was released 2018-12-27 .
In F-Droid itself you also can jump many versions back if you have to.
I really think the annoying of nearly 100% of the users to force them to update F-Droid just after installation of F-Droid all the time is not valuable over the maybe this one single user who have to be pointed at F-Droid | F-Droid - Free and Open Source Android App Repository to download an older version and test if the older version fixes his issue. You also just want this one single user who have the problem to contact you so that you know there is a issue.
We all agree that having an older version on the download button is not
ideal. I think there is 100% consensus on that. Unfortunately, there
isn’t much testing of fresh installs, that’s the issue here.
What needs to happen is someone needs to actually do the testing of the
new releases on fresh installs across a wide variety of Android versions
and devices. Making the change to the website via merge request is a
one line change.
How often do you have bugs that only present themselves on fresh installs but don’t appear on upgrades?
It has happened in the past, that’s the data I have. I’d welcome better data.
I would imagine that this type of bug would be exceedingly rare.
The only scenario where I can imagine this happening is if the SQL database code for creating the database has a typo, but the code for upgrading the database does not.
That being the case, if a build of F-Droid has passed sufficient testing and validation to be declared stable and recommended for upgrade in the app, the only additional testing that would need to be done is to do a fresh install on one device. Testing fresh installs on multiple devices has no additional benefit, because the SQL creation code will run the same across all of them. Any other bug that would only manifest on certain devices would have already been discovered during the testing and validation that already occurred before the build was marked stable.
If someone wants to do the testing and be responsible for cleaning up
the mess when something breaks, I’ll happily defer to them on
maintaining of the version on the download button. When I do it, I want
to be conservative, based on experience. What is really not appealing
to me is someone else updating the version there, and me cleaning up the
mess.
This is one of those type of discussions that is sometimes difficult to have in the abstract. Perhaps it would be beneficial to deal with some concrete examples. These would allow us to get a better feel for the nature of the issue.
Looking at those details should give us a lot of information on the best way forward.
I agree that this conversation should be concrete, thanks for moving
that direction. Unfortunately, I don’t remember specifics about the
previous problems. I just remember the update approach we developed. I
imagine the details of previous issues are in the issue tracker.
I think I can remember two kinds of issues in the past:
things in the FDroidApp.onCreate() startup sequence that only crashed
on first time installs, not update
bugs in the database initial setup that were handled properly in the
DB update code
Perhaps a better way to address this is to develop an automated test
sequence for this specific case. There are already basic Espresso tests
for F-Droid client and CI runs in the emulator. Then this new
automation would have to make sure the device/emulator is starting from
a clean F-Droid state (e.g. uninstall F-Droid), then run on as many
devices and Android versions as possible.
If someone is setup for Firebase or some other device testing service,
that would be ideal.
Whatever the solution, the current state of things reflects poorly on the project. This is an example of a situation where, to avoid a rare problem that might never occur again, they introduced a constant problem that occurs all the time.
For a new user trying out F-Droid for the first time, installing the version from the website and then instantly being told that version is out of date and they need to install another one leaves the impression that F-Droid isn’t well organized and perhaps shouldn’t be taken as a serious app repository. I am not aware of any other major open source project that functions this way, even though all of them have the potential to release a version that works on upgrades but not on new installs. Everybody else has found better ways to deal with that unlikely scenario.
I agree its less than ideal. Also consider: Every time you install an
OS from scratch, Windows, GNU/Linux, macOS, etc. the vast majority of
the time, you are prompted to install updates. It is a common situation.
yes, that’s true, but now and then there are also bugfix releases e.g. ubuntu 18.04.3 LTS. just to minimize update orgies respectively security reasons. So, I’m in favor for providing the current (stable) apk version.
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.
And the question remains: who does that additional testing?