Do you mind if I write a request to be added to F-Droid? about wakelock-revamp HOT 13 OPEN

I don't mind.

from wakelock-revamp.

@d4rken
What to specify in the field developer and developer mail?
It is also desirable to tell the site of the developer

from wakelock-revamp.

AuthorName: Matthias Urhahn
AuthorEmail: [email protected]
AuthorWebSite: https://darken.eu
Donate: https://github.com/sponsors/d4rken

SourceCode: https://github.com/d4rken-org/wakelock-revamp
IssueTracker: https://github.com/d4rken-org/wakelock-revamp/issues
Changelog: https://github.com/d4rken-org/wakelock-revamp/releases

from wakelock-revamp.

How do I write a title? Wakelock or Wakelock Revamp

from wakelock-revamp.

@d4rken

from wakelock-revamp.

"Wakelock Revamp" or "Wakelock 2"

from wakelock-revamp.

@d4rken I'm currently working on getting your app working with the F-Droid build system. One thing I have to note so far: as you calculate the versionCode and versionName dynamically, we have to update the metadata manually every time you release an update. May I ask why you do it this way and why you can't hardcode it, like most apps do?

from wakelock-revamp.

@d4rken I'm currently working on getting your app working with the F-Droid build system. One thing I have to note so far: as you calculate the versionCode and versionName dynamically, we have to update the metadata manually every time you release an update. May I ask why you do it this way and why you can't hardcode it, like most apps do?

So i just have to increase one number in one place and everything else is calculated.
If I have to bump values manually then it's easy to make mistakes such as changing the wrong versionCode digits.

For other project I have set it up to take the major/min/patch values from a properties file this also worked well, but would also not work with F-Droid?

I find F-Droids way of doing this a bit inconvenient and unflexible ☹️. Is there anywhere I can read up on why it is setup the way it is and what other options might have been discussed?

With CI I could even do some kind of webhook to notify F-Droid? Which would also be good for F-Droid server resources as it would trigger processes after the build has actually build successfully...

from wakelock-revamp.

@d4rken I'm currently working on getting your app working with the F-Droid build system. One thing I have to note so far: as you calculate the versionCode and versionName dynamically, we have to update the metadata manually every time you release an update. May I ask why you do it this way and why you can't hardcode it, like most apps do?

So i just have to increase one number in one place and everything else is calculated. If I have to bump values manually then it's easy to make mistakes such as changing the wrong versionCode digits.

Actually version Code just needs to be greater then the one of the last releases. Android does not really care what digits you change. Anyway if you want to continue your normal workflow, we could go for manually updating metadata, but be aware that this might make the time it takes for updates to appear inside F-Droid even longer.

For other project I have set it up to take the major/min/patch values from a properties file this also worked well, but would also not work with F-Droid?

Yeah those projects will not work very well too, but CWA is a special case in F-Droid anyways, so it does not matter that much there.

I find F-Droids way of doing this a bit inconvenient and unflexible frowning_face. Is there anywhere I can read up on why it is setup the way it is and what other options might have been discussed?

The exact problem we have here is discussed in fdroid/fdroidserver#388. But basically we currently only are able to get the versionName and versionCode statically by reading the gradle files, but not interpreting them as gradle code. If we would actually run gradle on them we could simply get the values from the gradle runtime and don't care how they are calculated, the problem is, that people could run malicious code on our checkupdates runners that way. To fix this we would need to spin up a VM/container for every app to check, which would require a lot of ressources.

As an alternative we offer UpdateCheckData which could get the versionCode and versionName from files via flexible regexes (but again no calculation, like you do to produce the versionCode) or we could request some URL (e.g. an API)

With CI I could even do some kind of webhook to notify F-Droid? Which would also be good for F-Droid server resources as it would trigger processes after the build has actually build successfully...

I'm not aware of such efforts currently, but feel free to open an issue so we could keep track of your idea.

from wakelock-revamp.

Actually version Code just needs to be greater then the one of the last releases. Android does not really care what digits you change. Anyway if you want to continue your normal workflow, we could go for manually updating metadata, but be aware that this might make the time it takes for updates to appear inside F-Droid even longer.

In this case version code is simple. In apps running multiple releases or wear-os components it get's more complicated (for some platform deficit reason wear-os needs to be a second package with a different version code).

The request to be added to f-droid was created on multiple of my projects, I'm looking for a solution that can be applied in general. If it's easy, I'd do it for every new app I make, other devs would probably be more open to it too. But with all the extra requirements it is often only an after-thought 🤷. I don't use F-Droid myself, but I like it, I like the spirit, but I dread churn and overhead.

The exact problem we have here is discussed in fdroid/fdroidserver#388. But basically we currently only are able to get the versionName and versionCode statically by reading the gradle files, but not interpreting them as gradle code. If we would actually run gradle on them we could simply get the values from the gradle runtime and don't care how they are calculated, the problem is, that people could run malicious code on our checkupdates runners that way. To fix this we would need to spin up a VM/container for every app to check, which would require a lot of ressources.

Thanks for the link.
I agree that would take a lot more resources. Seems no decision was made. Simple parsing logic + arithmetic would have worked for me, but I now think the only sane solution in the long run would be to get the information via gradle, just having to bite the bullet on resources. F-Droid needs someone to sponsor this 😁.

As an alternative we offer UpdateCheckData which could get the versionCode and versionName from files via flexible regexes (but again no calculation, like you do to produce the versionCode) or we could request some URL (e.g. an API)

Any extra version information would be written by the release CI job, and the release CI job is triggered by tagging a commit (which is imho a sane workflow?), but afaik the information needs to be available to F-Droid when at or before a tag is created. So this is kinda a catch-22 🤔.

So a do it all solution would be something like a release bash script that I execute, which does the version calculations, bumps them, writes them into gradle and then tags and releases. Sounds brittle 😓

I'd prefer to not have the app manually maintained on F-Droid which would inevitable get outdated and then cause headaches with users coming around with old bugs that have already been fixed...

from wakelock-revamp.

Okay so how do we proceed for now? You create your bash script and a new releases with it and then I could enable automatic update on the F-Droid side?

from wakelock-revamp.

I'm kinda drained by the whole thing already ☹️.

I have no idea when I would find time and motivation to work on such a script.
I'm not good at bash scripts 😅. PRs welcome 😄.
Or F-Droid adds more options to the update checker that are compatible with my workflow. ☕

I don't really work on this app anymore, it is "done" feature wise, and there are no real bugs.

If you want to create a PR that changes the versioning for this project, I'd merge it.

from wakelock-revamp.

If this app is actually more or less completely developed, we could just go for manual updates. I mean it seems like you don't expect that many updates anymore in the future, so it shouldn't be that much work for the F-Droid team.

from wakelock-revamp.