versionCode and releases #30
Comments
|
It seems, |
|
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 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. |
|
I see.
|
|
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 So I'll stick with the |
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.
It could be pretty real:
So there is no way to test an app thoroughly enough. See issue #22 for example. If you really need something with
You can stick with
These will be always correct. |
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
As pointed out above, I told my updater to stick to 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 Oh? Looks like the version compare can deal with that, comparing Still, users won't receive any update notifications as |
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. |
|
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 |
|
Just picking up the question again, as today my updater once more informed me about there being a problem with |
|
It doesn't make much sense to put an app in a repo if it doesn't offer updates:
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" 🙊 |
|
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). |
|
Thanks a lot! Please let me know when it's there so I can adjust my updater accordingly to pull the right files. |
|
Ready. From now on:
|
|
Thanks a lot! 🤩 Adjusted the config here and triggered an update check: updater no longer complains, users will receive update notifications – wonderful! PS: If you want to add the link next to the PlayStore one: |
It seems that since MkIIIv34,
versionCodewas never increased: it's still stating90. As Android uses this to tell versions apart, new releases are never announced to the user.Further, the current tag naming makes it hard to automatically fetch updates (I just noticed today that I missed quite a few of them, as
MkIIIv34compared againstMkIV_dev20_releasewas interpreted as34 > 20and thus the new tag being ignored). Can you please clarify the difference between MkIII and MkIV? Looks like these are two "branches" released at the same time.For fetching updates it would help enormously having tag names with clear versioning as well as corresponding
versionNameorversionCode(you could e.g. use prefixes as you currently seem to do:mkiii_<versionCode>andmkiv_<versionCode>would be great as that way you cannot forget increasing it either 😉)Thanks in advance!
Edit: I've now defined
MkIIIvas prefix with my metadata, and that seems to do the trick for the automatic updates, but due to the unchangedversionCodethey won't be brought to the users' attention (no update announcement).The text was updated successfully, but these errors were encountered: