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.