initial Fastlane structures from IzzyOnDroid

[IzzySoft]

Here's your starter kit :smiley: Be welcome to build on it. For guidance, you can use the IzzyOnDroid Fastlane Documentation – which is an improved version of "the other link" you just received (which was the snippet I started collecting details for the documentation with).

Should there be any questions, just ask. Now, enjoy!

[IzzySoft]

I see you modified the full description, converting it to Markdown. You're aware that F-Droid.org does not support Markdown? That's why I sent you HTML. F-Droid will render the current file as plain text; IzzyOnDroid can handle Markdown fine. Further you replaced the icon by a very small one; no prob with that, but that makes it just a "dark blob" with nothing recognizable. Sure you want it that way?

[anonfaded]

I see you modified the full description, converting it to Markdown. You're aware that F-Droid.org does not support Markdown? That's why I sent you HTML. F-Droid will render the current file as plain text; IzzyOnDroid can handle Markdown fine. Further you replaced the icon by a very small one; no prob with that, but that makes it just a "dark blob" with nothing recognizable. Sure you want it that way?

oh i thought i have to add the icon from the directory where android studio created the iamge assets, i now modified it and added the full size pic, its in landscape so will f droid auto adjust it? also i changed the markdown to html, please check now if its fine.

[IzzySoft]

Please make sure you read and understand the details in above linked documentation: IzzyOnDroid Fastlane Documentation. The icon must be squared, so no landscape: 512x512 or 256x256 or 128x128 or 96x96 are fine, like the one from here

As for the description, please take a look at the one I provided here. It looks weird to just have a bullet-point list and no description. Also, yours has a bunch of line breaks in which F-Droid will replace by <br> – that's why the file provided here had all HTML put into a single line. Once more, the linked documentation gives you some hints on that.

[anonfaded]

Please make sure you read and understand the details in above linked documentation: IzzyOnDroid Fastlane Documentation. The icon must be squared, so no landscape: 512x512 or 256x256 or 128x128 or 96x96 are fine, like the one from here

As for the description, please take a look at the one I provided here. It looks weird to just have a bullet-point list and no description. Also, yours has a bunch of line breaks in which F-Droid will replace by <br> – that's why the file provided here had all HTML put into a single line. Once more, the linked documentation gives you some hints on that.

I have fixed the icon size and made the description like you provided earlier, kindly check now.

[IzzySoft]

Thanks! That looks fine now and should also result in a nice display at F-Droid.org.

By the way, be prepared to be asked which commit you've built the APK from that is attached to your new release. It does not seem to match the commit the tag points to.

[anonfaded]

Thanks! That looks fine now and should also result in a nice display at F-Droid.org.

By the way, be prepared to be asked which commit you've built the APK from that is attached to your new release. It does not seem to match the commit the tag points to.

oh i haven't noted the exact commit but i think it was this one: https://github.com/anonfaded/FadCam/tree/b0cd3bb9e42deec971305defb3c2d51eb121d942 Actually i built the apk from the version which was final at that time, right now i have pushed many more commits and added a new feature of bottom_nav_bar, but as its not complete so i haven't added it to the apk yet bcz i want to add it once the feature is fully implemented. I just pushed the changes to my repo here and haven't incremented the versioncode bcz right now i don't want it to be in the production version. So that commit which i mentioned on top is the one i want to be on F-Droid, also can you guide on it; like if i push commits to my repo here but dont increment the version code or name, it will be fine right? and when i increment that then it will be updated on F-Droid? or do i need to make issue on F-Droid to update my app there?

[anonfaded]

Also i saw that on this link: https://apt.izzysoft.de/fdroid/index/apk/com.fadcam there is an older version of app with old icon and description, can that be updated too

[IzzySoft]

oh i haven't noted the exact commit but i think it was this one

The APK attached to a release should always be built from the commit the release points to (if possible, rare exceptions might apply).

So that commit which i mentioned on top is the one i want to be on F-Droid

F-Droid builds from tags, so it will build from the commit your tag points to. That's what tags are for: indicating which commit you consider to be a (stable) release. Looks like you'll have to fix this up another time then :wink:

like if i push commits to my repo here but dont increment the version code or name, it will be fine right?

Sure, that's how it's supposed to work (and why F-Droid will build from tags, and why the APK at a release should be build from the commit the release points to).

there is an older version of app with old icon and description, can that be updated too

That will be fixed once a new release is pulled in. So once you've cleaned up the above, we can take care for that. Usually, new releases are detected automatically by the updater – but as the current 1.0 would technically be the same version as your latest 1.0.0, the updater ignored it (rightfully).

If you let me know once a new release is ready, I can check if it's fine (hopefully before the updater catches it, just to make sure).

[anonfaded]

F-Droid builds from tags, so it will build from the commit your tag points to. That's what tags are for: indicating which commit you consider to be a (stable) release. Looks like you'll have to fix this up another time then 😉

okay so i have to fix this as this is the only issue now, so i checked and this is the commit i want to have in stable release: https://github.com/anonfaded/FadCam/tree/b0cd3bb9e42deec971305defb3c2d51eb121d942 so what should i do now to fix it? like in my android studio should i revert back to this commit and generate the signed apk, and then delete the tag and make new tag with this apk? but how will it have this commit when the current repo is around 10 commits ahead from what i need in stable version. Need some help to not mess it up further😅

Or if this isnt possible and i have to build from the latest commit and make the incomplete feature in the stable version in new tag, then letme know so i can do it. I will try to figure out myself too but you can guide better.😊

[anonfaded]

@IzzySoft I have fixed it, hopefully it will be fine. Now it points to the commit that i wanted: https://github.com/anonfaded/FadCam/releases/tag/1.0 i followed these commands to fix my stable release:

# Delete the existing tag locally
git tag -d 1.0

# Delete the existing tag from the remote repository
git push origin :refs/tags/1.0

# Checkout the desired commit
git checkout b0cd3bb9e42deec971305defb3c2d51eb121d942

# Create a new tag pointing to the desired commit
git tag 1.0

# Push the new tag to the remote repository
git push origin 1.0

Let me know if there are still any issues.

[IzzySoft]

I'm no Android dev and have never worked with Android Studio – but basically the path sounds right. I meanwhile figured what happened, so no fix needed from your side at this time; if you're curious, expand the following

Notes:

Let me make it a bit more precise: 1. `git checkout b0cd3bb` to set the local repo to that commit 2. in Studio, build and sign the APK 3. in your local repo, go back to your current `HEAD`, then create a new one pointing to the wanted commit: `git tag 'v1.0' b0cd3bb`. To the repo, the only thing changed at this point should be that there's a new tag. 4. push that tag to Github (`git push --tags`), create the corresponding release and attach the APK to it Note that I do not recommend deleting and replacing the existing tag (which I consider something one should only do in very rare cases where there's no alternative to that). Not just because of consistency, but also due to a Github bug: it might well be that the release will be invisible after this (if a tag with the same name existed before, Github messes up) – so you might better choose a different tag name. May I suggest `v1.0`? That would also meet best practices then, as the leading `v` ensures it's always seen as a string (and not mistaken for a float). Then also stay with that for future releases.

oh i haven't noted the exact commit but i think it was this one: b0cd3bb

Well, afraid not. It rather seems you made some changes after that commit but did not commit them, then built the APK, and only then committed. There's a commit hash embedded in your APK at META-INF/version-control-info.textproto:

repositories {
  system: GIT
  local_root_path: "$PROJECT_DIR"
  revision: "b2ab78b6e1dcd77fbd08133586fa3831219943ed"
}

So your APK was built between that commit and the next one. The next commit (16fa77bd677cf4d235572c43590a126fd6c3c657) is the one adjusting versionName and versionCode, which is already reflected in the APK. So this is indeed what happened: right after you built the APK, you committed the changes. So just skip the "fixing" in above "hidden notes" (but make sure for future releases to do it right). Should F-Droid complain, your listing there can probably wait for the next release then, given your app is already available at IzzyOnDroid. But we can deal with that when they complain, no need to do that before :wink:

For future releases, just remember the correct "release workflow": test your build (making sure versioning etc. are also OK), then commit everything, then build the APK (not before the commit!!!), tag that commit and create the release, so everything is in sync.

[anonfaded]

you warned about not to delete tags etc but before this i already deleted and updated new release, i hope it won't create issue with the F-Droid now.

leading v ensures it's always seen as a string (and not mistaken for a float).

If i understood it right, here i need to use v with version? For example if i decide to make new release with a new feature, i need a new tag like v1.1 ? And also i will need to increment that versionCode and versionName in studio and then commit everything and build + generate signed apk right

And with new release the latest commit will automatically be mentioned in the release i guess.

As everything seems fine right now, i will wait for F-Droid to respond with something so i can see it in their repo.

[IzzySoft]

i hope it won't create issue with the F-Droid now.

No, but it would have had they already built from that tag. Same for IoD btw. Apologies for not being clearer before – I thought I already mentioned that last ime, maybe over in the issue?

If i understood it right, here i need to use v with version?

Not need – and not there. git tag 1.0 would have to be git tag v1.0 then. It's the tag that counts there. So that's the place to add the v if you want to do that.

make new release with a new feature

You always increment versionCode and adjust versionName, yes. How far to adjust the latter is your choice. You could orient at semantic versioning. And yes: increment, then commit, then build & tag, then make the release.

And with new release the latest commit will automatically be mentioned in the release i guess.

The release is based on the tag, and the tag points to the commit.

As everything seems fine right now, i will wait for F-Droid to respond with something so i can see it in their repo.

Which will take a while, but yes.

[anonfaded]

Which will take a while, but yes.

got it, i understood it now.

they already built from that tag.

and now how can this be resolved? Can you update it so they again build from the tag that i have in releases right now?

You could orient at semantic versioning.

And i want to use semantic versioning from upcoming releases, so i will make it 0.2.0 right? where i only add new feature and no bugfixes, and then when i fix bugs i will increment the patch one like 0.2.1, never done this before so it was little confusing.

[IzzySoft]

and now how can this be resolved? Can you update it so they again build from the tag that i have in releases right now?

Wait what they say. If they ask you can say you re-created the tag and the APK, so they should retry.

And i want to use semantic versioning from upcoming releases, so i will make it 0.2.0 right?

No. You are already at 1.x, so that would be a downgrade. You could even stay at your current schema – I rather meant to orient at the principle. With SemVer, a.b.c, increasing c means minor patches/fixes, increasing b major things (like important features added), and increasing a a "breaking change". So with your a.b you could say minor changes increase b, and major ones a, for example.

[anonfaded]

You are already at 1.x, so that would be a downgrade.

Alright, i wanted to share some updates. I have fixed a bug and for that i created a new tag v1.0.1 , and followed all the steps you mentioned earlier, built the apk from same commit and attached to the release. Now this is the latest stable release: https://github.com/anonfaded/FadCam/releases/tag/v1.0.1 i will leave a comment on F-Droid issue on GitLab too to let them know.

btw i posted this on f droid gitlab issue but from a day they havent responded and issue is still open...

[IzzySoft]

Congrats, that looks perfect now! And no worries, answers there take a little sometimes. There's a load of issues, and only few people working on it. The team at IoD is even smaller, but we don't have as many incoming issues here.

That said, I wonder why your Readme already has the F-Droid badge (pointing to an empty page), but not the IzzyOnDroid badge (where your app is already available). Maybe you want to pick a badge and link it to your app there? https://apt.izzysoft.de/packages/com.fadcam would be the link for it. It will take at least a week or two before your app becomes available at F-Droid. And you might wish to keep your app at IzzyOnDroid, where updates are published much faster, I guess – even when it became available at F-Droid?

[anonfaded]

I added the F-Droid badge in advance, so when it gets online it will directly open it😅. And i haven't added the IoD badge yet bcz it is having old version of app with old icon and apk, so if it gets updated then for sure i will add that badge too.

[IzzySoft]

i haven't added the IoD badge yet bcz it is having old version of app with old icon and apk

Ugh? F-Droid has no version at all but you've added the badge :stuck_out_tongue_winking_eye: Well, you just released the new version a few hours ago. It was already updated here in staging (along with its icon – that's how I knew it "looks perfect now": I had manually triggered the updater, and all went smooth) and will show up on the production server with the next sync around 6 pm UTC, so you can prepare the badge already :wink:

[anonfaded]

thanks! also i added the badge in readme for IoD :)

[IzzySoft]

Thanks a lot! :star_struck:

[anonfaded]

@IzzySoft hey 👋🏻 i wanted to ask that if i want to make a release but for beta version and not stable, and i don't want that to be on F Droid, IoD, should i directly add it to release without a tag? Like it will not be detected by F droid as its not having a tag right?

Also is it fine to increment the version for beta one and later use that same version for stable without incrementing again?

[IzzySoft]

if i want to make a release but for beta version and not stable, and i don't want that to be on F Droid, IoD

For IoD you could simply tag it as pre-release (that would be ignored by the updater unless explicitly enabled – as it's done for some apps having their betas here and their stables there). For F-Droid, you could have a tag prefix defined to pin to (that would work with IoD as well btw). Like, currently your tag names are v<versionName>, which corresponds to v%v in F-Droid's syntax. You can have them define only to pick those tags – and release your "other" ones as eg beta-<versionName> to have them skipped.

With IoD, both variants work by default. With F-Droid you'd need to have that tag name prefix defined in their metadata (something that's done by default at IoD).

Also is it fine to increment the version for beta one and later use that same version for stable without incrementing again?

While technically possible, I'd not recommend that – as those having the beta installed would not get notified about the availability of the release (or a subsequent beta before that). Android uses that internally to tell versions apart, so when you made the release, a device with the beta installed would ignore that thinking it's already installed.

[anonfaded]

With F-Droid you'd need to have that tag name prefix defined in their metadata

how can i add this to metadata? and the tag syntax should be beta-1.0.2 for example ? but what if i make a release without any tag so f droid wont detect that at all?

While technically possible, I'd not recommend that – as those having the beta installed would not get notified about the availability of the release (or a subsequent beta before that). Android uses that internally to tell versions apart, so when you made the release, a device with the beta installed would ignore that thinking it's already installed.

and to fix this issue, do i need to increment the version in beta and then the stable after it will also be again incremented? i hope i understood it right

well right now the f-droid still haven't approved my app but for new versions it will auto updated on f-droid or do i need to open issue on their fdroiddata repo to update my app? i saw an issue template their about updating app thats y asking.

[IzzySoft]

how can i add this to metadata?

You need to request that at fdroiddata – either via an issue or, if you can, via a merge request.

and the tag syntax should be beta-1.0.2 for example ?

No. You want them to only pick tags named v<versionName>, right? I'd suggest opening an issue at fdroiddata and explain your needs, they'll know what to do.

but what if i make a release without any tag so f droid wont detect that at all?

A release is always based on a tag. So if there's no filtering, that tag would be picked up for builds by F-Droid.

and to fix this issue, do i need to increment the version in beta and then the stable after it will also be again incremented? i hope i understood it right

You did :smiley:

well right now the f-droid still haven't approved my app

Yeah, takes a bit longer there as with IzzyOnDroid :wink: If your RFP was not yet fully processed (i.e. the corresponding MR not yet merged or even not yet created), don't create a new issue in fdroiddata but put that into a comment at your RFP.

but for new versions it will auto updated on f-droid or do i need to open issue on their fdroiddata repo to update my app?

It will be auto-updated. That's why we're dealing with tag naming here, right? It's possible to have auto-updates disabled, but that somehow defeats the purpose. It already takes 3..5 days for your new releases to show up there with auto-update – now think how long it would take if you'd always need to ask for manual action…