android: rm APK_VERSION, and change versionCode calculation #9221
Conversation
Use our own logic to go from ELECTRUM_VERSION to numeric android versionCode, instead of using the default conversion done by python-for-android. Even before this, we were already patching p4a to modify their logic (see [0]). This commit changes that logic again, and moves it into a separate script in our repo. - calculation change is due to the f-droid maintainers asking for the arch code to be in the least significant digits (instead of most sig digits) (see [1]) I have pushed and changed to a new p4a branch, which is just a copy of the previous one with 3 commits related to versionCode calc squashed. [0]: SomberNight/python-for-android@edb7e4f [1]: spesmilo#9210 (comment)
|
I'm not sure if offset is needed, we simply can make a major release (I know there's no breaking change, but it would help android versioning to be much simpler to reason about, and easier to predict). then first digit will be def get_android_versioncode(*, arch_name: str) -> int:
version_code = 0
# add ELECTRUM_VERSION
app_version = "5.0.0" # <--------------------------- added for testing
app_version_components = app_version.split('.')
assert len(app_version_components) == 3, f"version str expected to have 3 components, but got {app_version!r}"
for i in app_version_components:
version_code *= 100
version_code += int(i)
# add arch
version_code *= 100
arch_code = ARCH_DICT[arch_name]
assert len(arch_code) == 1
version_code *= 10
version_code += int(arch_code)
# note: up until version 4.5.5, we used a different scheme for version_code.
# 4_______________4_05_05_00
# ^ android arch, ^ app_version (4.5.5.0)
# legacy scheme is now compensated by a major release:
# 44050500 ---> 50000004
return version_code |
| # ^ android arch, ^ app_version (4.5.5.0) | ||
| # This offset ensures that all new-scheme version codes are larger than the old-scheme version codes. | ||
| offset_due_to_legacy_scheme = 45_000_000 | ||
| version_code += offset_due_to_legacy_scheme |
There was a problem hiding this comment.
I'm not sure if offset is needed, we simply can make a major release (I know there's no breaking change, but it would help android versioning to be much simpler to reason about, and easier to predict). then first digit will be
5, which is higher than previouslyx86_64's4
As long as the major version number is a single digit (which will be true for the foreseeable future), this 45 million offset is equivalent to a simple "45" string prefix. I don't think that's too complicated.
I don't think we want to do a major version number bump just for this.
There was a problem hiding this comment.
hmm, are you sure you don't want to put room for patch? if patch ever goes to two digits (ex, 4.5.10), it will fail.
currently for 4.5.5 it yields 45405054
There was a problem hiding this comment.
it's actually fine, I ran some more examples and all looked fine to me, even though I thought it would not be fine.
4.1.50 -> 45401504
4.10.5 -> 45410054
4.10.50 -> 45410504
10.1.5 -> 46001054
10.10.50 -> 46010504
|
Also it would be nice if we could include the base version code in the git tag name, so it can be picked up by f-droid for |
Do you mean having git tag names such as I searched for VercodeOperation and found https://f-droid.org/en/docs/Build_Metadata_Reference/#UpdateCheckMode but it's still not clear why we should put the full versionCode into the tag. Setting the tag to the version string should be just as good I think. (We have been naming git tags as basically Btw re release workflow, we typically push a git tag, and then start building binaries after. The build takes a long time and we also cross-compare it across multiple people doing builds (to check reproducibility) and only then upload them to the webserver. So the http links for a new version only become live ~1-2 days after a git tag is pushed. |
|
hmmm, the delay could cause some issues, not necessarily as f-droid build cycles are like 7 days apart. the worst is it gets disabled until manually enabled through a MR again about the version code. we need some way to either:
the issue is this specifically: https://gitlab.com/fdroid/fdroidserver/-/issues/1228 |
|
checking the other metadata files, it seems they also support loading the version from a remote url: |
|
Well there is https://electrum.org/version. It is a json file. EDIT: would it solve this if we put the "base" versionCode into that json file? |
It is also available in the website git repo btw, along with the rest of the website: It is generated as part of the release process, in |
|
Re this PR in particular, if there are no objections (?), I will merge it. |
LGTM
edit: I saw that there's a HTTP check mode (I just saw the docs for it), so it's gonna be fine. putting the versionCode in there is gonna work out pretty well I think |
This can be used by the F-Droid buildserver to detect new versions and release updates automatically. ref: spesmilo#9221 (comment) https://f-droid.org/en/docs/Build_Metadata_Reference/#UpdateCheckMode
This can be used by the F-Droid buildserver to detect new versions and release updates automatically. ref: spesmilo#9221 (comment) https://f-droid.org/en/docs/Build_Metadata_Reference/#UpdateCheckMode
This can be used by the F-Droid buildserver to detect new versions and release updates automatically. ref: spesmilo#9221 (comment) https://f-droid.org/en/docs/Build_Metadata_Reference/#UpdateCheckMode
This can be used by the F-Droid buildserver to detect new versions and release updates automatically. ref: #9221 (comment) https://f-droid.org/en/docs/Build_Metadata_Reference/#UpdateCheckMode
This drops the trailing .0 from the version number of android apks. It is a historical thing that we don't need/utilise anymore. (Some years ago, prior to reproducible builds at least, sometimes we had .1 and .2 releases just for android-specific bugs.)
Related #9210 (comment)
Also, the android
versionCodecalculation is changed to accommodate the changed version string, but also to have the architecture part in the least significant digits, as requested in #9210 (comment)@thecockatiel Could you check if this looks good to you? (re version string and int version code construction)