Comments (14)
Ready.
From now on:
-
*-versioned-*
flavors have the standard versioning. -
*-downgradable-*
flavors uses thereleaseVersionCode
application metadata bundle field.
AnotherTerm/app/src/downgradable/AndroidManifest.xml
Lines 1 to 10 in f9806e5
from anotherterm.
Sorry for the late response.
Ok. I'll add a new fdroid flavor for both branches in the next release (in case you prefer MkIV-dev once).
from anotherterm.
It seems, MkIIIv
and MkIV-dev
version prefixes are pretty good to represent both branches now. I'm not planning to remove the -dev
suffix soon. I hope, you have a way to publish two applications with the same ID as it makes interchangeability between Wayland and stable (master branch) editions much simpler.
from anotherterm.
No, applicationId is unique per app. While using the same applicationId would make cross-updates easier, it would also make accidental cross-updates easier – as Android wouldn't know they are different apps. So here's what would happen with automatic updates then: "you have com.foobar
installed with versionCode: 5
? Oh, there's a com.foobar
with versionCode: 6
, let me update that for you…"
With different tag naming patterns, I can tell my updater which one to pick, so users of my repo wouldn't receive "accidental cross-updates". But I could not serve both apps simultaneously if they share the identical applicationId.
from anotherterm.
I see.
- Same
applicationId
- In this case, it's better to preferMkIIIv
branch. (I wonder why the FDroid infrastructure still lack of some feature to switch between branches with the sameapplicationId
.) - Same
versionCode
- What about downgrade? (I also wonder why the FDroid infrastructure still does not provide some alternative versioning scheme to trick the Android to downgrade seamlessly (without wiping the app data).)
from anotherterm.
Well, many people wonder many things. If F-Droid provided those features, they'd wonder the other way around – and complain about degraded security 😆
Why a downgrade to a lower versionCode
is no longer possible (it once was) you must ask those who made that rule. Probably because that could break things (imagine an upgrade changed the structures of your local SQLite database. How'd you expect the older version to deal with that?). Plus honestly, how often have you needed to downgrade? The very few times I had, I simply uninstalled and restored from backup.
So I'll stick with the MkIIIv
branch/flavor then for my repo. How can we ensure I don't pick an APK from the other one accidentally? Please remember that possibility should you one day decide to drop the suffix. And will you consider increasing versionCode
?
from anotherterm.
...imagine an upgrade changed the structures of your local SQLite database...
Imagine, you have a pretty large amount of data. I see no reason to copy it forward and backward for nothing. Why Google does not simply provide some kind of an opt-out option in case I can deal with forward compatibility by myself? That's weird.
Plus honestly, how often have you needed to downgrade?...
It could be pretty real:
- Android OS images cannot provide you with the exact details of real devices behavior;
- Android device farms are usually have no relatively old devices.
So there is no way to test an app thoroughly enough. See issue #22 for example.
This particular application MUST have a way for quick downgrade.
If you really need something with versionCode
semantics, It's possible to use some other place in APK for it. I'll do it a bit later.
So I'll stick with the
MkIIIv
branch/flavor then for my repo...
You can stick with
- any releases on the
master
branch
or - the release names match
^Mk([IVXLCDM]+)v([0-9]+)$
where$1
- (latin) major part;$2
- minor part of the version.
These will be always correct.
from anotherterm.
Why Google does …
I've stopped asking that question long ago. See e.g. Your app is not compliant with Google Play Policies: A story from hell. And yes, I'd also prefer some adb install -r --force
for such cases – but we don't have it.
the release names match
^Mk([IVXLCDM]+)v([0-9]+)$
As pointed out above, I told my updater to stick to MkIIIv<versionName>
– but taking a closer look, that won't fetch any updates at all as the version name is MkIIIv\d+
. So not only users won't receive update notifications as versionCode
isn't increased – my updater does not even have a chance fetching any updates (without accidentally fetching the wrong ones). And no, I cannot implement another exception handling just for a single app. The last one currently in my repo is a v53 dating 2021-05-02 (which is probably the date the first release with that versionCode
was made, as the file date correctly states 2022-06-02). This is a mess. And I cannot even go by the suffix (you're appending a _release
to ALL tag names). And I cannot go by the file names either, as those are the same for MkIII and MkIV.
So with the current setup, I can either fetch no updates at all – or run the risk fetching the wrong ones. I can only specify exactly one RegEx on the tag name – and that then must include a place holder for either versionName
or versionCode
(so I don't have to download the APK everytime only to find out it's still the old one).
Oh? Looks like the version compare can deal with that, comparing MkIIIv53
(the last release in my repo) against 54_release
(resulting from the mentioned RegEx), finding the latter being newer. Patrick did a great job providing me that rewrite 🤣 So it seems at least at that part we're good.
$ ./getRelease.php -vp green_green_avk.anotherterm.redist
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/releases'
green_green_avk.anotherterm.redist: checking tag 'MkIV_dev21_release'
green_green_avk.anotherterm.redist: checking tag 'MkIIIv54_release'
green_green_avk.anotherterm.redist: lastRelNo set to '54_release', checking for files
Upstream file date (2022-07-07 22:15) is newer than ours (2021-05-02 02:00).
green_green_avk.anotherterm.redist: returning ['54_release','https://github.com/green-green-avk/AnotherTerm/releases/download/MkIIIv54_release/app-redist-release.apk']
green_green_avk.anotherterm.redist: MkIIIv53/54_release, GH https://github.com/green-green-avk/AnotherTerm/releases: https://github.com/green-green-avk/AnotherTerm/releases/download/MkIIIv54_release/app-redist-release.apk
- Grabbing update for green_green_avk.anotherterm.redist: OK
Binary files green_green_avk.anotherterm.redist_90.apk and green_green_avk.anotherterm.redist_54_release.apk differ
green_green_avk.anotherterm.redist_90.apk already exists, quarantining before replacing it with update
- Checking 'green_green_avk.anotherterm.redist_90.apk' for libraries and malware …
..
Still, users won't receive any update notifications as versionCode
again remained unchanged.
from anotherterm.
...And no, I cannot implement another exception handling just for a single app...
It seems, the only thing you need to do is to add to your updater an ability to specify a short lambda function on per app basis to parse tags... It will be a general solution.
In this case the lambda will look that simple (JavaScript):
(tag) => {
const parseRoman = (input) => {
const nn = { I: 1, V: 5, X: 10, L: 50, C: 100, D: 500, M: 1000 };
return [...input.toUpperCase()].reduce((pv, cv, ci, a) =>
nn[a[ci + 1]] > nn[cv] ? pv - nn[cv] : pv + nn[cv], 0);
};
const m = /^Mk([IVXLCDM]+)v([0-9]+)_release$/.exec(tag);
return (m ? (parseRoman(m[1]) << 16) + parseInt(m[2], 10) : null) || null;
}
If you provide me with a link to your code, I could do it for you.
from anotherterm.
Thanks! But making the code more complex for a single app is not what I'd go for (especially when it turns out that part does work – but the code update would break it for the 800+ other apps in the repo 😉) No, the only thing missing now is the update notification for the users of the app. Which cannot be fixed unless the versionCode
will be increased.
from anotherterm.
Just picking up the question again, as today my updater once more informed me about there being a problem with versionCode
and I had to search why (cannot remember details for all the apps, apologies): Will you increase versionCode
properly with the MKIII redist
APK at least, which is the one I pick? Those users who want a not-changing versionCode
could come to your releases section and pick another one manually, as they need to update manually anyway. But those who prefer update notifications and maybe even automated updates could still receive them via my repo then.
from anotherterm.
It doesn't make much sense to put an app in a repo if it doesn't offer updates:
- as
versionCode
is never increased, there won't be any update notifications - even if the user checks manually, there won't be any "update" button (for the same reason); and even though F-Droid offers "downgrades", that possibility doesn't exist either as there are no "previous versions" due to all of them being "the same"
- so all left is to manually download the APK file and side-load it – which is not how an app-repo works or what it is intended for; essentially concerning this specific app it doesn't make much difference if it's in the repo or not, apart for initially discovery and install
So @green-green-avk may I suggest a last time to have an APK with proper versioning? If you prefer it without, maybe just attach it as a separate APK, and mark it with "proper versioning for UPGRADABILITY" 🙊
from anotherterm.
Thanks a lot! Please let me know when it's there so I can adjust my updater accordingly to pull the right files.
from anotherterm.
Thanks a lot! 🤩 Adjusted the config here and triggered an update check: updater no longer complains, users will receive update notifications – wonderful!
$ iod repo get green_green_avk.anotherterm.redist
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/releases'
green_green_avk.anotherterm.redist: checking tag 'MkIV_dev41_release'
green_green_avk.anotherterm.redist: checking tag 'MkIIIv74_release'
green_green_avk.anotherterm.redist: lastRelNo set to '74_release', checking for files
Upstream file date (2023-03-08 04:39) is newer than ours (2021-05-02 02:00).
green_green_avk.anotherterm.redist: returning ['74_release','https://github.com/green-green-avk/AnotherTerm/releases/download/MkIIIv74_release/app-redist-versioned-release.apk']
green_green_avk.anotherterm.redist: MkIIIv73/74_release, https://github.com/green-green-avk/AnotherTerm/releases: https://github.com/green-green-avk/AnotherTerm/releases/download/MkIIIv74_release/app-redist-versioned-release.apk
- Grabbing update for green_green_avk.anotherterm.redist: OK
- Checking 'repo/green_green_avk.anotherterm.redist_133.apk' for libraries and malware …
green_green_avk.anotherterm.redist: check if repo contains FUNDING.yml
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/.github'
green_green_avk.anotherterm.redist: Github reports "Not Found" for https://api.github.com/repos/green-green-avk/AnotherTerm/contents/.github
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/'
green_green_avk.anotherterm.redist: no FUNDING.yml detected.
green_green_avk.anotherterm.redist: calling 'getFastlaneMeta(github,[host:github.com,owner:green-green-avk,repo:AnotherTerm,path:/fastlane/metadata/android])'
green_green_avk.anotherterm.redist: FastlaneFeatures shortdesc,fulldescMD,icon
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/fastlane%2Fmetadata%2Fandroid'
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/fastlane%2Fmetadata%2Fandroid%2Fde'
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/fastlane%2Fmetadata%2Fandroid%2Fen-US'
green_green_avk.anotherterm.redist: looking for 'https://api.github.com/repos/green-green-avk/AnotherTerm/contents/fastlane%2Fmetadata%2Fandroid%2Fen-US%2Fimages'
green_green_avk.anotherterm.redist: checking locale 'de'
green_green_avk.anotherterm.redist: checking locale 'en-US'
PS: If you want to add the link next to the PlayStore one: https://apt.izzysoft.de/packages/green_green_avk.anotherterm.redist/
(you could also pick a badge for that if you wish).
from anotherterm.
Related Issues (20)
- Audio in graphical session HOT 3
- About wayland scanner (scan.py) and source generating HOT 2
- MANAGE_EXTERNAL_STORAGE
- Support styled and colored underlines HOT 3
- Terminal color is too dark to see HOT 8
- Built-in command to operate android clipboard HOT 3
- With Font iconsolata not display completely HOT 3
- A mask is displayed when Returning back to terminal HOT 3
- Charset list is not displayed correctly in terminal HOT 6
- termsh cannot send cleartext http request on android 13 HOT 2
- Wayland support: missing XDG-WM-Base protocol HOT 4
- armeabi-v7a re-support HOT 8
- Weird error when trying to execute sh ./repo-linuxcontainers.sh HOT 4
- lsusb after libusb setup crashes debian bookworm root session HOT 8
- Unable to access CTAP2 device to backup in Debian PRoot HOT 6
- Text direction HOT 6
- proot ubuntu/debian unable to ssh HOT 1
- Suggestion: the selection pop-up menu in the terminal
- Non-monospace characters rendering HOT 2
- [FR] Add ability to have hook script when toggling android on screen keyboard HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from anotherterm.