Include pre-releases in the F-Droid repo

[codenyte]

Is Your Feature Request Related to a Problem?

No response

Feature Description

Publish the builds, which are marked as pre-releases on GitHub Releases, on F-Droid. I've seen some apps do this before, but I'm not exactly sure how to set this up. I looked at the F-Droid documentation, and apparently you just need to put the unstable release in F-Droid and set the latest stable version as the CurrentVersion field in F-Droid build metadata. That way, F-Droid should only install stable releases by default, but should also allow installing beta builds, if the user enables the "Allow Beta Updates" toggle. Maybe @IzzySoft can help with this?

Alternative Solutions

Currently I use Obtainium to download the nightly builds from GitHub releases

Additional Context

No response

[IzzySoft]

The app is currently in my repo, but pre-releases are disabled. Due to the APK size (already slightly exceeding the per-app-size-limit of 30 MB), only the latest version is available there – so enabling pre-releases would mean that, whenever a pre-release was pulled, no stable release would be available – so I don't think this is a good idea.

Your description points to the build strategy at F-Droid.org; to my knowledge Thunder isn't available there (or it must be using a different applicationId for the F-Droid build). For my repo, that's a simple toggle; by default, pre-releases are skipped. If the authors want them to be pulled as well, that can be done – but due to the outlined issue I'd recommend not to.

If you were asking about F-Droid.org, I cannot help you with that as I'm currently not active at F-Droid.

[codenyte]

Your description points to the build strategy at F-Droid.org; to my knowledge Thunder isn't available there (or it must be using a different applicationId for the F-Droid build). For my repo, that's a simple toggle; by default, pre-releases are skipped. If the authors want them to be pulled as well, that can be done – but due to the outlined issue I'd recommend not to.

Sorry, I didn't realize that there were differences between the official repo and yours in regards to building applications. I thought it was the same procedure, thanks for clarification.

@hjiangsu We could consider submitting Thunder to the official F-Droid repo or maybe host a custom repo on GitHub.

[hjiangsu]

Due to the APK size (already slightly exceeding the per-app-size-limit of 30 MB), only the latest version is available there

Ahh I didn't know about this - thanks for mentioning it! If I can reduce the app size below 15MB, would that allow the possibility to have nightly/pre-releases on the repo? This might be do-able if I split the APK per ABI.

If this is the case, which version would be hosted on the repo (armeabi-v7a, arm64-v8a, or x86_64)? Unfortunately, I'm not too familiar with Android practices so any insight would be helpful. I'll still most likely include all three APKs separately within a given GitHub release.

We could consider submitting Thunder to the official F-Droid repo or maybe host a custom repo on GitHub.

This is already in the works as mentioned in this PR: #347. I believe the main issues are solved already, but I'm just waiting until the stable release of 0.3.0 before I continue with the F-Droid requirements/validation.

[codenyte]

I would avoid split APKs, as they are kinda annoying to deal with. We could continue just shipping the stable release on IzzyOnDroid and once Thunder gets released on F-Droid.org, we could also add the unstable builds using the procedures I outlined in my original comment (if that works, because I'm not exactly sure about it).

[IzzySoft]

Sorry, I didn't realize that there were differences between the official repo and yours in regards to building applications.

F-Droid builds from source. My repo retrieves the APKs the developers provide.

If I can reduce the app size below 15MB, would that allow the possibility to have nightly/pre-releases on the repo?

Depends. 15 MB or less would allow for 2 releases to be kept. But if e.g. a "stable release" is followed by multiple "pre-releases", we'd have the same situation again: no stable releases available. There'd be other approaches to this, like

• using different applicationIds/packageNames for stable and pre-release (e.g. give the latter ones a suffix like .nightly). That would make it separate apps which could co-exist
• apply for listing at F-Droid.org and have e.g. them shipping the stable releases while keeping the pre-releases with my repo. Combined with establishing reproducible builds there, folks could cross-update when needed.

which version would be hosted on the repo

Per your preference, one of the ARM builds. x86 devices are rather rare.

I would avoid split APKs, as they are kinda annoying to deal with.

First time I hear this. The only disadvantage is that, for my repo, we'd need to decide for one ABI then – and depending on whom you ask it will always be the wrong one 🙈 While theoretically 64bit devices can run armeabi builds as well, there are very few exceptions (I know only of a single exception, some Google Pixel 7 pro, where Google disabled 32bit support) – while the other way around, no 32bit device could run arm64.

we could also add the unstable builds using the procedures I outlined in my original comment

Which would require updates at F-Droid to be set to manual IIRC, as otherwise (same as here) stable releases would be moved to archive leaving only pre-releases in main, and also pre-releases would be marked as "recommended version".

[codenyte]

Thanks for the explanation.

I would avoid split APKs, as they are kinda annoying to deal with.

First time I hear this.

I mean this in the way, that AABs would suck for users who manually download the releases from GitHub, instead of using F-Droid or Google Play.

using different applicationIds/packageNames for stable and pre-release (e.g. give the latter ones a suffix like .nightly). That would make it separate apps which could co-exist

I'm not a big fan of this approach, because it doesn't allow for smooth updates from stable to nightly/pre-release.

apply for listing at F-Droid.org and have e.g. them shipping the stable releases while keeping the pre-releases with my repo. Combined with establishing reproducible builds there, folks could cross-update when needed.

I think this might be the best solution.

[IzzySoft]

I mean this in the way, that AABs would suck

Ah, different term. You refer to app bundles (AAB), I refer to "split APKs" (separate *.apk files).

because it doesn't allow for smooth updates from stable to nightly/pre-release.

No. But it allows you to test if a certain "fix" is working with a planned "stable release" before that stable release is being made, by temporarily installing the pre-release without uninstalling/altering the stable one.

I just outlined the possibilities I see – and will accept the approach the app team prefers. Which probably is for @hjiangsu to say then 😉

[codenyte]

I mean this in the way, that AABs would suck

Ah, different term. You refer to app bundles (AAB), I refer to "split APKs" (separate *.apk files).

Oh, you mean seperate APKs for each architecture? Ok sure, that makes sense. I was a little confused there.

No. But it allows you to test if a certain "fix" is working with a planned "stable release" before that stable release is being made, by temporarily installing the pre-release without uninstalling/altering the stable one.

Yeah I also thought about that, and I'm genuinely surprised that Android doesn't allow the user to downgrade an app to an older version. But considering that Thunder pre-releases tend to be rather stable (at least all the ones I tried), and the user isn't forced to download pre-releases, I don't think this would pose a big issue. But that's up to @hjiangsu to decide.

[IzzySoft]

you mean seperate APKs for each architecture?

Exactly that, yes.

I'm genuinely surprised that Android doesn't allow the user to downgrade an app

Oh, there are good reasons for that (e.g. database upgrades rarely have a downgrade procedure in the older APK, because how should that work?). But there would be possibilities. Like having a flag like minCompatibleVercode, pointing to the oldest version one could safely downgrade to, and allowing downgrades that far. But well, it's not done and so we have this situation…

[codenyte]

you mean seperate APKs for each architecture?

Exactly that, yes

Ok, then I take back my previous statement, where I was confused about AABs and seperate APKs for each architecture. AFAIK those shouldn't pose an issue to the user. I just hate AABs (I know that they make sense in certain cases, but not in this one).

Oh, there are good reasons for that (e.g. database upgrades rarely have a downgrade procedure in the older APK, because how should that work?).

That really makes sense, I should have thought about that. Thanks again, I learned so much from this thread.