Closed binarynoise closed 1 year ago
A few structural corrections: the name for the screenshots directory must be phoneScreenshots
, not phone-screenshots
. Also, some of your full_description.txt
are wrongly named as full-description.txt
(the underscore is correct, the dash is not). Similar typo with some short-description.txt
(also must be an underscore).
My updater would tread your "full descriptions" as "standard Markdown", so empty lines separate paragraphs (simple line-breaks don't). Should work as far as I can see, but please check if it's how you intend it to be.
I cannot speak for the other parts (outside metadata/
), so I didn't check those. Should you have some icons for the modules, please place them as images/icon.png
next to their corresponding text files.
Thanks! With the above fixed, that should work fine for my repo.
I fixed the issues you pointed out, it got lost in the TTT -> fastlane restructure.
I intended the full descriptions as Markdown so I had the paragraph rules in mind.
The apps don't have icons (yet) so there are no icons in the module metadata.
Thanks! Seems to be fine so far (on a quick glance – I'm a bit short on time currently, having been AFK for a couple of days and needing to catch up with the backlog). One note, though:
title.txt
is not a short description, it's used as the app name (and overrides that). So e.g. for de
of AutomaticAdvancedSettingsExpander, it seems not what it should be – but that's of course up to you.You're right. I wasn't creative enough so that actuality is the app's title. I might come up with a better idea later but for that is how I want it to be.
Thank you for taking your time for me.
Gladly! Just wondering: is https://github.com/binarynoise/AutomaticAdvancedSettingsExpander still maintained then? Where will its APKs be published (as there are no releases here)? And shall I already include the metadata from here with my repo (i.e. preparing that for the next release – wherever that might appear then)?
No, I will archive that repo soon.
I plan to release updates here. Speaking of that, how do I actually release apks here so the repo will pick them up and tell them apart?
If including the metadata means that as soon as there is a release for that app it will show up in the repo, go ahead.
No, I will archive that repo soon.
Please give me a ping when I shall switch then – which requires the first release to be available here already then.
If including the metadata means that as soon as there is a release for that app it will show up in the repo, go ahead.
No, if you move all modules in here, that will require some work on my end as well. Multiple apps in a single repo is always a bit problematic. One point you raised already:
how do I actually release apks here so the repo will pick them up and tell them apart?
And what release tag for which app? Will each have its own tag, or will there be one tag for all? There are multiple options, but they all require more discipline than if each app would have its own repo.
aase-<versionName>
for releases of the AutomatedAdvancedSettingsExpander, bbds-<versionCode>
for BetterBluetoothDeviceSort, and so on. Each of those tags/releases then should only hold APKs for that one app.app-release.apk
, you can use the very same prefixes there.While from my point of view, separate repositories would be the first choice, dedicated tag names (option 1) would be the next. Dedicated file names would be the last resort – but with more than 2 apps I cannot tell how reliable that would be if e.g. a tag only has updates for one app and not for the others; my updater is not intended to walk the entire tag tree – and neither for such a big mix (there's no other repo I've encountered so far doing that, so I never had any need to test this out).
Solely relying on file names is probably a bad idea, I agree, so I'd go the separate tags for each app route. I talked to a friend (the one that is already contributing his modules as well) and he also favours the one repo for all apps instead of an org that has one repo for each app.
I need to admit that I didn't have those things in mind when I built this repo (I was learning all the other metadata stuff).
For the tag names I would suggest using the package names for them, aliases are great but require maintenance on your side whenever a new package is added.
As for the discipline thing, I'll probably create a small shell script that will handle the versioning and creation of new releases.
Sounds good! Let me know then when I should look to integrate the next one.
@IzzySoft I created the first release: https://github.com/binarynoise/XposedModulets/releases/tag/de.binarynoise.AutomaticAdvancedSettingsExpander-v6 Does the format fit your scripts?
So I use de.binarynoise.AutomaticAdvancedSettingsExpander-v%c
(with %c
representing the versionCode
) as tag names to consider – fits. Let me know when I shall perform the switch to the new repo and pick up the first release from there.
(PS: apologies for the delayed response, I was on vacation when your notification arrived here)
I think you can switch now. The other apps now have their releases too.
OK, switched this one over and enabled Fastlane for it (fulldesc should render fine as Markdown). You might wish to check the results once the next release was pulled – that is, today around 6 pm UTC. You might e.g. wish to put things like setInitialExpandedChildrenCount
and PreferenceGroup
into back-ticks, so they render as <code>
.
That said, which other modules would you declare as "ready for pick-up" so I add them to my repo? I see Fastlane is prepared for another 6 already (didn't check if the corresponding tags are).
Oof! Looks like you also changed the signing key? On purpose or by accident? A different signing key means "update impossible" (and implies "possible repo hi-jack" – signing is a security feature). My repo does not accept the new APK as the certificate does not match the configured one. I can of course override that, but must be sure then. And whoever has the previous version installed needs to know they have to uninstall/re-install if you really mean it.
That's probably by accident. I'll look into it.
I accidentally overwrote the signingConfig
in common.gradle.kts
so it wasn't using the one it should have used.
I published a new version with the correct signature.
Which other modules would you declare as "ready for pick-up" so I add them to my repo? I see Fastlane is prepared for another 6 already
The other ones can be picked up as well, except for de.binarynoise.dontResetIfBootedAndConnected
. Do you prefer the ignoreme
or should the directory be missing completely?
I published a new version with the correct signature.
That one checks out again, thanks! Will go live with the next sync in the evening.
The other ones can be picked up as well
Will look after that later, now is "bed time". As for "ignoreme": I only pick up what I've set up. So if the corresponding app is not set up, its metadata won't be referenced, right? Then no worries :wink:
OK, just added "Free Notifications" and "Reset all Notification Channels" now. There are no graphics in the Fastlane structures, maybe you could add some? In general, an icon (missing with "Automatic Advanced Settings Expander" as well) and some screenshots would be good.
Oops, can you please fix Fastlane here: https://github.com/binarynoise/XposedModulets/tree/main/metadata/de.binarynoise.betterBluetoothDeviceSort/en-US/en-US/
? Everything needs to be moved a level up (duplicated locale level, won't work).
I removed that superfluous directory.
Anything else that I missed? :sweat_smile: Do you know a linter that I can run on the metadata to check if everything is alright myself?
I removed that superfluous directory.
Thanks! Adjusted here. I meanwhile also added all other modules except the one you told me not to.
Anything else that I missed?
Just the graphics. At least an icon for each module would be nice, a screenshot or two (where applicable) would be welcome, to.
Do you know a linter that I can run on the metadata to check if everything is alright myself?
I have no linter for that. But what you could set up if you want is a check for the file sizes. e.g. shortdesc should be max 80 chars, fulldesc max 4000 (make the latter better max 3500, as HTML-conversion might add to it), title 50 chars IIRC. And check how they're rendered once they are up, in case you want adjustments :wink:
Add metadata for F-Droid/IzzyOnDroid
Continuation of https://github.com/binarynoise/AutomaticAdvancedSettingsExpander/pull/3