jellyfin-archive / jellyfin-android-original

Android Client for Jellyfin
https://jellyfin.org
GNU General Public License v2.0
272 stars 65 forks source link

F-Droid Build Recipe #308

Open logancgarcia opened 4 years ago

logancgarcia commented 4 years ago

For the past few days, I've been writing and testing a build recipe that will allow Jellyfin to be on the F-Droid app store. I've tested it using a local version of the F-Droid build server. Here is the source code for the build recipe:

https://gitlab.com/Feral2k/fdroiddata/-/blob/new-app-jellyfin/metadata/org.jellyfin.mobile.yml

The rest of the metadata, such as the description and screenshots, are here:

https://gitlab.com/Feral2k/fdroiddata/-/tree/new-app-jellyfin/metadata/org.jellyfin.mobile/en-US

I wanted to open up an issue to allow further discussion on the topic and, if given the go ahead to create a merge request into F-Droid, have something to link to so that the maintainers know that the Jellyfin developers have approved of the app being on F-Droid. There are a couple things worth mentioning about the app being included in F-Droid:

  1. At it's current state, if we include the app on F-Droid, it will not be able to automatically update on new versions of the application. This is because F-Droid requires a version code to be present in the repo before any compilation begins. For Cordova applications, this can be achieved by including the version code in the config.xml in the root of the directory, but it appears that that was removed as it was considered redundant (see https://github.com/jellyfin/jellyfin-android/pull/51), which I completely understand. If we reinclude this version code, we can automatically build the app on each tagged release.

  2. The metadata, including the images and description, cannot be sourced from the repo as that would require that the repo have a structure for metadata that reflects what either Fastlane or the Triple T Gradle Play Publisher have. I have therefore, to the best of my ability, copied the relevant metadata into the F-Droid metadata directory.

dkanada commented 4 years ago

Is the version code really 909 and not 099 to match the integers? Cordova was generating that and I never actually check the value. Regardless, we definitely support inclusion on the official F-Droid repository!

If we reinclude this version code, we can automatically build the app on each tagged release.

This is also totally fine since it's such a minor change. The codebase has changed a lot since then so it's not as much of a problem now.

The metadata, including the images and description, cannot be sourced from the repo as that would require that the repo have a structure for metadata that reflects what either Fastlane or the Triple T Gradle Play Publisher have. I have therefore, to the best of my ability, copied the relevant metadata into the F-Droid metadata directory.

I've been setting up some improved CI lately for automatic builds on Azure, and I was thinking of adding some form of automated uploads at some point which might involve either of those two libraries. Your current solution sounds fine for now though. A few of my personal repositories have the metadata stored in an F-Droid specific folder but I'd rather use a more universal method here.

logancgarcia commented 4 years ago

Is the version code really 909 and not 099 to match the integers? Cordova was generating that and I never actually check the value.

I believe so, yes. Cordova seems to autogenerate the version code from the version number by referencing the version number as:

MAJOR * 10000 + MINOR * 100 + PATCH

https://cordova.apache.org/docs/en/latest/guide/platforms/android/#setting-the-version-code

So in this case, it would be 0 10000 + 9 100 + 9, which is 909.

If you want, I can set up a PR to reinclude the version code for v0.9.10 (which, in that case, would be 910) and then modify the F-Droid build recipe for autobuilds once you tag and release v0.9.10. After that, if everything is successful, I can update this thread for a final confirmation before making a PR with the F-Droid data repo.

I've been setting up some improved CI lately for automatic builds on Azure, and I was thinking of adding some form of automated uploads at some point which might involve either of those two libraries.

Awesome! I'll keep an eye out for that!

dkanada commented 4 years ago

I was actually considering a jump to 1.0.0 because image loads will be almost entirely fixed, resume and live TV will be working, and a basic download feature will be added in the next release.

logancgarcia commented 4 years ago

That's great to hear! It'll be nice to have the first version on F-Droid be v1.0.0 as well! In that case, the version code would be 10000, if we're going to stick with the way Cordova is creating version codes.

dkanada commented 4 years ago

You might get 0.9.9 added successfully before we push another release, depends on how fast I can get everything finished.

logancgarcia commented 4 years ago

That's very true, but I'd rather not make a PR into F-Droid followed by another PR to allow automatic builds if we plan to include the version code in the next release. I'd prefer to make just one PR that includes the ability to automatically build it.

dkanada commented 4 years ago

@Feral2k I checked the metadata, the description still has a stray link to https://jellyfin.media but the org address is preferred. Also, the warning about base URLs should no longer be an issue so I would remove that as well. I'm aiming to release 1.0.0 by Sunday, so let me know if the version code I added will work for you.

logancgarcia commented 4 years ago

Gotcha. I'll make those changes. And I checked out the version code in the config.xml and it looks perfect! That's exactly what I needed!

Anglodel commented 4 years ago

Absolutely glad to read that the app will be in F-Droid repositories ! Thank you, @Feral2k !

logancgarcia commented 4 years ago

Alright, after testing the latest release and confirming that auto updating is in place, I made the appropriate changes to the build recipe and submitted the pull request. I think we should keep this issue open until it is successfully merged.

@Anglodel Of course! Thank you for the kind words!