APK available?

[IzzySoft]

I see a release, but no way for a non-dev to "get the app". Could you make the (signed) APK available – eg. by attaching it to the release? Thanks in advance!

[leonlatsch]

@IzzySoft The app is currently submitted at GPlay and FDroid. I didn't plan on giving out a signed apk.
Once one or both of the store entries are ready, I will reply here.

[IzzySoft]

@leonlatsch thanks! Of course, if you already submitted it to F-Droid (and our packagers manage to get it into the index in timely manner), there's no need to attach the APK here. I see you submitted it directly via MR (which is why I missed it; I'm rather responsible for RFP, where the Requests For Packaging usually start), and one of our packagers already chimed in – so that shouldn't take too long then.

Thanks again – and sorry for the noise!

[leonlatsch]

@IzzySoft GPlay is now online

[IzzySoft]

Thanks for the pointer! Added to my app list 😃

[leonlatsch]

@IzzySoft Thank you, thats nice :)

[IzzySoft]

Guess I'll have to add a new group for gallery apps with a vault (or vaults which act as gallery, depending on the point-of-view). If I do, I'll move your app into that group so it stands out a bit better.

[IzzySoft]

PS: it might take a little longer until your app will be included at F-Droid (not enough packagers to manage the backlog). My offer with the APK in my repo still stands, should you want it there meanwhile 😉

[leonlatsch]

Thank you, but I can wait. I think its not good to have versions out there, that dont get updated over a standard channel.
Btw: I updated my mr cause for new versions. Is this the right way, or do I have to wait, till 1.0.0 gets packaged, before I can add version 1.0.1 and 1.0.2

[IzzySoft]

Thank you, but I can wait.

OK, your choice of course 😉 And "standard" is a question of definition 😄

I updated my mr cause for new versions. Is this the right way

Sorry, but I'm lacking context – so I have to guess what you are referring to. Yes, of course you can make new releases without having to wait your RFPs are processed. Metadata set up there are cross-checked by the packager who picks them up – and especially version info is then set to the latest one available. That will be the first packaged. And later on, should your pace of releasing be faster than F-Droid's packaging (happens with some apps, like FairEmail) – well, some interim versions might be skipped then, which should be no problem. Should you need a faster update pace than F-Droid offers (like FairEmail does with its daily releases), my offer stands: this is eg the reason why FairEmail is in both repos.

[leonlatsch]

So the packagers will take care of updating the version, in my case?
Skipping imterim versions is not a problem for me. I just wondered, if the took version 1.0.0 even if 1.0.2 is alrealy released, so I added 1.0.1 and 1.0.2 to the mr.

[leonlatsch]

How would the update process work with your repository?. I just don't want old versions of the app laying around without any "standard" way of updating.

[IzzySoft]

so I added 1.0.1 and 1.0.2 to the mr.

Eh, that they will complain about. If it's an MR already, simply adjust it to only have the latest release referenced (avoiding unnecessary builds).

How would the update process work with your repository?

My updater checks for new tags once a day. If found, and there's an APK attached meeting configured criteria¹, it is pulled and placed into my repo. On index build, if the number of available APKs exceeds the configured threshhold (usually 3 APKs – or as many as fit into the limit of 30M, whichever is lower), the oldest APK gets removed. So there are never more than 3 APKs per app. I can limit that further for your app if you want: given the current size of <5M it would be 3 APKs here, but I'd recommend leaving it at the described default.²

¹ _{some repos have multiple APKs attached; so I can eg configure here to only pick the *-noanalytics.apk – or ignore all (amd64|intel|mips) files.}

² _{given how F-Droid works: users have the index of all apps on their device. So if they choose to install your app shortly after it was updated on the server, they might refer to the "previous version" – so it's a good idea to keep at least one.}

I just don't want old versions of the app laying around without any "standard" way of updating.

Nope, neither do I. My repo runs on personal space, not covered by "big fundings". So I have an interest in keeping it "slim" 😉

[leonlatsch]

Okay, I will change my mr to only have the newest version.
And I will add APK to the releases, so you can add them to your repository.

[IzzySoft]

Thanks! (PS: please give me a ping once the APK is attached)

Depending on your release frequency (and maybe other arguments): Shall I keep it in my repo (daily updates) once it made it to F-Droid.org (approx. weekly updates)? In ~80% of all comparable cases, I remove the app about a week after it got established there. Unless there's demand to keep it. I'm fine with both.

[leonlatsch]

I don't really have a release "schedule". The last 2 updates were hotfixes, for critical bugs and came out the same day. Could take a month till a new release or 2 weeks, so lets see :)

[leonlatsch]

@IzzySoft apks attached.

[IzzySoft]

I don't really have a release "schedule" …

Yes, of course – no need to make the decision know. We can see to that once your app got published at "F-Droid proper". And you might have your own reasons (unrelated to the release cycle) for keeping the app in my repo or not. As I wrote, I'm fine with either.

apks attached.

Thanks! Processing them now – will be listed with the next sync in about 4 hours; then you can find it here.

Btw: Please check your Fastlane. short_description.txt from de belongs to en-US and vice versa 😄 If you wish, I could also offer you a PR with slightly reformatted fulldesc (optimized to look good on all 3 places: F-Droid, my repo and Play, see here for some explanation; if you want to see results before deciding, check above link in about 4 hours).

Further: No need to duplicate the screenshots from en-US to other languages – en-US is always used as fallback for things not present in other languages. Oh, and you might wish to add that green banner from the readme as fastlane/metadata/android/en-US/featureGraphic.jpg – it even has the exactly right size (1024x500 is what is suggested for featureGraphic).