Fastlane doesn't work for F-Droid

[linsui]

F-Droid can only find the fastlane structure in root path. After the merging it's in android now. Could you please move it to root path? Thanks!

[github-actions[bot]]

Thank you very much for opening up this issue! I am currently a bit overwhelmed by the many requests that arrive each week, so please forgive me, if I fail to respond personally. I am still very likely to at least skim read your request and I'll probably try to fix all (real) bugs if possible and I will likely review every single PR being made (please, give me a heads up if you intent to do so) and I will try to work on popular requests (please upvote via thumbs up on the original issue) whenever possible, but trying to respond to every single issue over the last years has been kind of draining and I need to adjust my approach for this project to remain fun for me and to make any progress with actually coding new stuff. Thanks for your understanding!

[github-actions[bot]]

Hello there linsui! 👋

Thank you and congratulations 🎉 for opening your very first issue in this project! 💖

In case you want to claim this issue, please comment down below! We will try to get back to you as soon as we can. 👀

For more open ended discussions and/or specific questions, please visit the discussions page. 💖

[johannesjo]

Thanks for opening this up! I'll investigate!

[johannesjo]

You seem to have more knowledge about the subject than I do. The android code now resides in the android subfolder. Can I just move the fastlane folder to the root folder anyway?

[linsui]

Yep, you can just move the fastlane to root folder. A simple symlink also works. :)

[johannesjo]

Thank you!!

[linsui]

Thanks! Will the android app release new versions along with the whole project? Do we need to pick special tags?

[johannesjo]

Thanks! Will the android app release new versions along with the whole project? Do we need to pick special tags?

Yes! That is the plan. Not sure about the tags yet tbh. :)

Automated builds are not yet set up. Do you have any experience with that by chance?

[linsui]

If android release uses the same tag then we don't need to do anything. If you want F-Droid to pick any special tag, e.g. xxx-android, just ping me. :)

[johannesjo]

@linsui (and also @jiongxuan) I have a question regarding versioning and I thought you might be able to help me. For desktop and web we are currently on the version 10.0.11 for android we are on versionCode 30 and versionName "30.10.0.11". For desktop and web I just need to run npm version patch and then the version script in the package.json (and then github actions) takes care of everything else. How would you deal with android? I guess that we would need to extend the version script in the package.json with a script that upgrades the version inside the build.gradle file by upgrading versionCode by one regardless of the type of release. How would you approach this? Is there a ready standard solution for it?

[linsui]

It works for F-Droid as long as the version code is increased for every version. You can increase it by one. You can also convert the version name to version code, e.g. 3010011.

[jiongxuan]

@johannesjo @linsui, thanks for the suggestion!

The reason we initially went with “30.10.0.11” for Android was because the previous version was “23.0”, so aligning with the main version would appear as a “downgrade” to users. We also wanted to highlight this as a significant update, which is why we chose the 30.x.x.x format.

Regarding versionCode, I agree with your approach and am considering converting it to a “30100011” format (with an extra zero for each segment, like 30.10.00.11). This would make the versioning easier to maintain. As long as there are no major changes, we could keep “30” consistent and just increment the patch numbers as needed.

What do you both think of this approach?

[linsui]

LGTM!

[johannesjo]

What do you both think of this approach?

Generally I'd prefer something like 100011 (major_minor_patch each with 2 digits), since that's already enough numbers and the 30 is just a random number. Would there be any other negative drawbacks apart from a little confusion that the new version number is below the current?

[jiongxuan]

@johannesjo That sounds great! Just to clarify, are you suggesting this change for both versionName and versionCode, or only for versionCode? If it’s only versionCode, it shouldn’t be an issue since users won’t see it. However, if it’s also for versionName, there could be a perception of a “downgrade.”

I’ve actually been considering aligning versionName with the main version too. Even if it might cause a bit of confusion for users initially, it could simplify things overall.

What do you think?

[johannesjo]

if it’s also for versionName, there could be a perception of a “downgrade.”

I think this is OK since I assume that users usually don't pay too much attention to this anyway. I personally usually don't for mobile apps :) Lets keep things simple for us working on the project :)