So, what exactly are you recommending regarding the install version on the website and in the app?
I donāt think those can be compared. One site is not hosting an apk, but directing users to where they can get it (the latest version mind you) from multiple sources, while the other is hosting a download that doesnāt inform the user they are downloading an old version and requires them to upgrade afterwards, with no directions for the latest version apk on the website.
Of course itās not the biggest issue in the world but the reasoning here is really dubious and I honestly think itās just stubbornness and fear of the HYPOTHETICAL issue that could arise that would prevent people downloading the app suddenly. Not to mention itād have to be something that doesnāt occur on upgrading but only on installing fresh or otherwise itād be fixed. These things happen and people can understand if on a rare occasion there is some niche issue that they have to wait to be fixed. FDroid doesnāt seem to be pushing new features like the forks are that would make it unstable so I donāt see why this is a massive issue
I understand your concerns as a dev (you are the dev, not me), at the same time normie users (and me) care more about fast index updates (to come in 1.16 ;)) and real auto-updates (maybe on Android 12 or later devices, maybe via Device Owner etc)
What version in on website is a moot point, imho, does that work? Fine, does that crash? Ok, open an issueā¦ try the newer version from this apk, did it fix it? No? Badā¦ etc
Calling it āRED FLAG OMGā sounds like FUD to meā¦
An upgrade is not required in any shape or formā¦ you can stay on the site version and NEVER* update it if you wishā¦ just like your other appsā¦ you install one version and later you are REQUIRED to update? You reject apps updatesā¦ right? For all appsā¦Iām sure.
*not quite as indexV2 is already live so you might want that in the future
Wouldnāt it be more appropriate to do the same with the latest version? Does it crash, OK open an issueā¦ try the older version APK, did it fix it? No, bad
This way youād be improving the stability of latest releases. And itās what basically every other app does
Right, think this was said beforeā¦ feel free to test on multiple devices and Android versions, post those results here.
Why? Hasnāt that already been done? Many people use FDroid and lots on older devices.
I certainly agree that there are a lot of other important feature requests and bug report in F-Droid that deserve developer attention. If fixing this problem somehow required a lot of work then I would be in favor of putting it off in order to accomplishing more important things.
But the key to the solution is that fixing this doesnāt require any extra effort at all. All you have to do is agree internally if a release is beta or production and update the app and the website accordingly.
Ok, so this thread can be closed yes? The apk on the website is not the result of such an agreement?
Without trying to sound forceful, I donāt think it is a good look to close this thread without resolving the issue. Itās not like every update that came out after the one on the website was a beta, after all. It is fair to call it outdated.
Thereās no closing , just that it sounds odd to say āthe devs should decideā and then right after ābut not the current decisionā
/PS: I think I posted enough
I guess I just donāt follow the reasoning for the decision. But as I said itās not the end of the world, so Iāll agree with you that itās pointless to keep posting if evidently the outcome will not change. But youāll have to update the website APK at some point, no?
New Fdroid user here. Downloaded and immediately got a notice to update.
Just echoing how jarring that is ā from what i understand, the argument is that youād have to retest the release against all devices for a fresh install vs upgrade.
Maybe theres some nuances in the way this app works that means thats an actual concern, could someone try to explain or walk thru a failure scenario?
Is there a reason we cant just run regression/unit/intrgration (whatever is available) against the new releases prior to being promoted to the āstableā release?
What i have seen other projects do is offer the latest release but then below it offer the previous known stable. Kind of a compromise/stopgap that can be quickly implemented while we setup a proper release pipeline.