WhereYouGo
WhereYouGo copied to clipboard
Old version of WhereYouGo on F-Droid
From support mail:
According to your adopted App Wherigo: there is an old version on F-Droid. Is it an idea to delete or update that version? Cause that old version lead me (and maybe others) to the conclusion, that there are no updates anymore.
Any chance to remove it or take over that account?
See #79 - also the 0.9.3 ("beta") provided in the Releases does not install over 0.9.2 downloaded with F-Droid. It takes a full uninstall/install to get 20200308, hinting at different signing keys... AFAICT F-Droid was the/a major distribution channel back then
@steve8x8 The fact, that you cannot upgrade a version from Github over a version from another source is simple: We do not have access to the "real" signing key for technical reasons (its for historic reasons a shared secret key with other apps not open sourced...see other issue), so we have to use an intermediate key for all other channels except Google Play. This means in future the APK from Github will be potentially interchangeable with sources like F-Droid, etc. but not with Google Play.
What are your plans here?
The old version on f-droid is still being build everytime the job runs and fails: https://f-droid.org/wiki/page/menion.android.whereyougo/lastbuild_45
Do you want to include WhereYouGo in c:geo f-droid repo or update WhereYouGo on official f-droid repo?
I could file a merge request on the f-droid repo on gitlab to change the metadata for WhereYouGo and point the git repo URL to the new one here.
As I do not have any detail knowledge of the F-Droid processes I don't know what has to be done.
Do you want to include WhereYouGo in c:geo f-droid repo or update WhereYouGo on official f-droid repo?
Whatever is easier or technically possible.
I could file a merge request on the f-droid repo on gitlab to change the metadata for WhereYouGo and point the git repo URL to the new one here.
If this would be sufficient, why not. That would be great.
Ok, I'll file a change request, let's see if they allow an owner change of an app.
https://gitlab.com/fdroid/fdroiddata/-/merge_requests/6977
Hmmm, the dynamic versioning let the f-droid build fail:
https://gitlab.com/peter.storch/fdroiddata/-/jobs/601981402
The last Tag is 2020.04.07
, but the build produces a version of the current date 2020.06.18
:
ERROR: Could not build app menion.android.whereyougo: Unexpected version/version code in output; APK: '2020.06.18' / '20200618', Expected: '2020.04.07' / '20200407'
DEBUG: Error encoutered, stopping by user request.
Uploading artifacts for failed job
Can this be changed in the build.gradle?
@Lineflyer I think that we can release the legacy version "0.9.4" now.
@pstorch Can you create a version "0.9.4" from the legacy branch after the official release?
What was the code base to create the release for f-droid? The tag 2020.04.07
?
To publish this code base but with a static versionName/versionCode to f-droid - would it enough to checkout a branch from this tag and edit only the both parameter?
F-Droid scans the source repository for Tags (regex can be defined) to check what to build. At the moment old and new tags have same pattern (Numbers with dots). If you don't want every Tag deployed on F-Droid, you need to distinguish by tags (e.g. add a -fdroid to it). As a comment from the F-Droid reviewer the versionName could be ignored, but the versionCode needs to be as expected.
What is the purpose of the legacy branch? When we tag the releases of the legacy branch x.y.z-fdroid
or x.y.z-legacy
then we could instruct f-droid to build those.
@pstorch The legacy branch will support api15 devices, see #156 . The release is tracked in #165 . Can you create a F-Droid apk from 2020.06.25-legacy now or is it already too late with the yesterday date?
@bekuno there is no tag 2020.06.25-legacy
, yet. Should F-Droid only pick up and build for tags with -legacy
postfix?
The F-Droid configuration will not be a one off, it will define a pattern of tags to build automatically.
Should F-Droid only pick up and build for tags with
-legacy
postfix?
With and without this postfix.
I think that @Lineflyer will create the tag after successfull test by @kurly1 .
Ok, both legacy
and the normal release
should be published as separate versions on F-Droid? Then I guess a separate F-Droid config is needed.
Then I propose to use a normal version tag for the release
version and the -legacy
postfix for tags of the legacy version.
Then we still need to solve the dynamic version issue. Otherwise F-Droid cannot build it.
Edit: the legacy
version should also be build with a different app id then, probably menion.android.whereyougo.legacy
.
Edit: the legacy version should also be build with a different app id then, probably menion.android.whereyougo.legacy.
For Google Play we need to have the same packagr name. On F-Droid its up to you.
Versioning is already as you suggested. Normal release uses date and legacy appends a "-legacy" behind the date.
The tag is not yet done as its not yet published. Will tag after publish on Google Play.
Ah, I see it's published with the same id on PlayStore, but the legacy has the maxSdkVersion 15
. I'm wondering if that is possible on F-Droid, too. I need to check.
I found a way to overcome the dynamic versioning issue on the F-Droid build. Now it is building and setting the versionName to the Tag and the versionCode to the Tag without dots. New Tags with only numbers and dots will be built and published automatically. Next will be 2020.04.07.
Turns out to be more complicated. F-Droid build fails because of the ndk version which is needed. I'll have to figure out how to configure it correctly. Current merge request to fix the F-Droid build: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/7033
Finally the current version could be built and is available on the F-Droid repository: https://f-droid.org/en/packages/menion.android.whereyougo/
Would be interesting, if the legacy version can also be build when you tag it.
@pstorch Thanks for taking care of it. I have no idea about how F-Droid works exactly...only a rough idea.
Does it now update versions by using our repo tags automatically or do we need to trigger anything manually? Could I ask you kindly to add e.g. a wiki entry for this repository describing what needs to be done?
Does it now update versions by using our repo tags automatically or do we need to trigger anything manually?
Only the tag is needed, then the build is triggered automatically.
@pstorch There is a new tag 2020.08.21 from even that date. But on https://f-droid.org/en/packages/menion.android.whereyougo/ I do still see 2020.04.07.
Seems something is missing or not working?
Hmm, looks like the update check doesn't work. I'll have a look.
Looks like the dynamic versioning is again making trouble, this time while checking new tags. Why was it implemented like that? I would expect when I checkout tag 2020.08.21 and build it I get version 2020.08.21 and not version 2020.10.29 from today. That seems wrong.
https://github.com/cgeo/WhereYouGo/commit/9c329ca120eb74508726e798ef88febc04fe478b
It was implemented to allow to build a release version on CI bound to that date of creation. Can't you use the APK attached to the tag on Github instead for FDroid?
No, you cannot upload APKs to FDroid. FDroid always builds from source.
@bekuno Can we adapt the script you implemented to allow F-Droid to build a correctly versioned APK? See https://github.com/cgeo/WhereYouGo/pull/57
As an option you could add a build flavor for fdroid where the versionname and versioncode are fixed and use another buildflavor for CI.
Maybe we can in such a build flavor read the latest version tag from git and create the version info based of them. See eg. https://stackoverflow.com/questions/12602002/gradle-read-latest-xy-release-git-tag-for-versioning
Any update on this one?
In the meantime the version 2020.08.21 is published on F-Droid. I've updated the version code manually. But the build.gradle should really be fixed, so that F-Droid can recognise new versions automatically.