Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any plan to include the app on Fdroid repo? #2

Open
much-doge opened this issue Apr 11, 2023 · 15 comments · Fixed by #13
Open

Any plan to include the app on Fdroid repo? #2

much-doge opened this issue Apr 11, 2023 · 15 comments · Fixed by #13
Assignees
Labels
enhancement New feature or request

Comments

@much-doge
Copy link

I would say this is a Firefly III android client which I like the most in terms of UI and ease of access, it would be nice for it to be included on Fdroid repository and I'm sure that way more people would know about it.

@dreautall
Copy link
Owner

dreautall commented Apr 11, 2023

Hi, thanks for the kind words! I'll have a look at how to publish on F-Droid once I'm ready to release the first non-alpha version.

Right now, I'm still unhappy with the notification reader feature which needs a more fine-grained settings menu to not be annoying. Once that's done (I hope in 1-2 weeks), a public version should be available, and I'll check how to publish to F-Droid!

@dreautall dreautall added the enhancement New feature or request label Apr 11, 2023
@dreautall dreautall linked a pull request Apr 23, 2023 that will close this issue
@dreautall dreautall reopened this Apr 23, 2023
@dreautall
Copy link
Owner

dreautall commented Apr 23, 2023

Current PR ongoing with the fdroid repo to include it: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/12959

@dreautall dreautall self-assigned this Apr 23, 2023
dreautall added a commit that referenced this issue Apr 24, 2023
Approval process takes some time, see issue #2
@much-doge
Copy link
Author

awesome 👍

@natrius
Copy link

natrius commented Sep 14, 2023

I have it.through the izzysoft repo, but it seems.to be stuck at 0.1.7-beta ?

@dreautall
Copy link
Owner

dreautall commented Sep 14, 2023

I'm honestly not sure how Izzysoft determines if there is an app update. For the official fdroid repo I created https://github.com/dreautall/waterfly-iii/blob/master/fastlane/metadata/android/version.txt, and just confirmed again that this works for the fdroid process (although due to issues with the reproducible builds, it is unfortunately still not "officially" part of the fdroid repo).

Not sure if @IzzySoft directly can help out here or if I'd need to create an issue at this GitLab.

@IzzySoft
Copy link

I'm honestly not sure how Izzysoft determines if there is an app update.

AutoUpdateMode: Version v%v
UpdateCheckMode: Tags

So my updater looks at the tags if there's a tag name indicating a higher version. Just triggered it manually now and it fetched v0.1.12-beta. Looking at the tag: That APK should have been fetched yesterday (and the other ones before that) – I have no idea why it didn't (the auto-update doesn't do anything different than the manually triggered one, just that the latter only considers the specified app). The logs show no errors either. Hope this was just a one-time hick-up; should it happen again, please give me a ping.

@kaanelloed
Copy link

@IzzySoft The app is still stuck at 0.1.7-beta , even with the manual update.

@IzzySoft
Copy link

@kaanelloed nothing I can do about that. 0.1.7-beta has versionCode 2096, so to Android that is newer than the 1993 from the current latest release:

package: name='com.dreautall.waterflyiii' versionCode='1993' versionName='0.3.0-beta'

versionCode must never be decreased, or things like this happen. Even if I'd pull this latest one to my repo and remove the 0.1.7, it wouldn't be offered to you as update – and if you tried to update manually, Android would refuse telling you that downgrades are not allowed. So you'll have to wait until the "base versionCode" (aka variant.versionCode) reaches 210 (which then results in 2103 for arm64) before updates will show up in my repo.

If you wonder how this might have happened, I have a good guess. Most likely, initially Flutter's own versionCode generation was used. Flutter takes the "base versionCode" and adds ABI * 1000 to it, with 2 for arm64. So with 0.1.7, the base versionCode probably was 96, which +2000 resulted in 2096. This calculation is a bit problematic, as it would count an older arm64 as newer than a recent armeabi. So the project decided to switch to a proper versioning, using the calculation variant.versionCode *10 + ABI. By that calculation, 0.1.7 would have had 963 (as arm64 was re-defined to 3 and 0.1.7 had 96 as base versionCode).

Maybe @dreautall wants to initialize the "jump" to variant.versionCode = 210 to fix this gap?

@dreautall
Copy link
Owner

Thanks for letting me know - I'll make sure versionCode is at least 210 for the next release (as I rely on automatic github builds it actually uses the github build number, which is at 203 right now, so getting it to 210 isn't too "hard" 😄)

@IzzySoft
Copy link

Yeah, thought the jump wouldn't be "too far" and thus acceptable 😜 Of course I could have simply replaced the APK here, but that would leave those at 0.1.7 and below stranded for another while. So going directly to 210 with the next release would solve it for all.

Thanks a lot, @dreautall!

@dreautall
Copy link
Owner

dreautall commented Dec 30, 2023

Should work now with v0.3.1-beta I hope (build number 213)

@IzzySoft
Copy link

Yupp, that worked out fine! Just the per-release changelog was not pulled as it could not be matched. So let me guess… I pick the arm64 one. According to your build.gradle that's a 3. At the very same it says versionCode x 10 + abiCode. I don't see where the base is established, but that would mean my 2133 must be 213.txt – and I can calculate that by (versionCode - 3) / 10. OK, I've set that, next release will show if it works (added the current changelog manually for now).

Let me check some more while we're at Fastlane. My notes say I don't pick shortdesc because it's too long (limit is 80 chars). That seems to be mostly fixed, except for

  • es-ES: 84
  • fr-FR: 98
  • pt-BR: 81
  • ro-RO: 89

Could you please fix that?

fulldesc is also skipped due to formatting issues: it's close to Markdown, but would only render as Github flavored Markdown, which my renderer does not support. Could you make sure it renders as "standard Markdown"? That means, paragraphs separated by empty lines, and bullet-point lists too.

@dreautall
Copy link
Owner

Hey. Unfortunately I implemented the length limit too late in Crowdin for short description, but I had to modify it for Google anyways and will update the files.

The text itself is not supposed to be any markdown as I just copy it into the Play Store description. Can I/you somehow mark it as plain text?

@IzzySoft
Copy link

will update the files

Please let me know when it's done, so I can enable those here.

Can I/you somehow mark it as plain text?

I can, but it won't look as good then (e.g. the longer lines in the bullet-point list would wrap on phone screens, thus destroying the formatting). All that would be needed to make it render as proper Markdown are two empty lines inserted: one before the bullet-point list, and one before the last line (after "Contribution:") – though the latter would not matter too much if you're fine with the two lines combined to a single paragraph.

dreautall added a commit that referenced this issue Jan 2, 2024
dreautall added a commit that referenced this issue Jan 2, 2024
@dreautall
Copy link
Owner

@IzzySoft: Should be all done, thank you for the feedback!

dreautall added a commit that referenced this issue Jul 20, 2024
dreautall added a commit that referenced this issue Jul 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants