Enhanced Version Detection (continuation of #132) #136
Comments
|
Same here. For me, it seems to have changed how it parses "v" as part of version string. e.g. it tells me to update from v1.0 to 1.0, even though there's no difference. |
|
Just got the same issue, to update app from 1.0 to v1.0. |
ImranR98
added
bug
|
I also had a number of apps tell me they need updates after installing Obtaonium 0.8.2 even though they were up to date. But re-downloading them seems to rectify the issue. |
|
Same issue too |
|
This should be fixed in the new release (hopefully, only did minimal testing): https://github.com/ImranR98/Obtainium/releases/tag/v0.8.3-beta For apps already affected, you'll need to manually mark as updated or re-install. But it shouldn't happen again after that. |
|
I update Obtainium to 0.8.3 and the version detection in the Obtainium repository seems to be wrong.
|
|
@ImranR98 the new version does seem to have different version parsing behavior, though it looks like only a subset of the ones I manually updated on the last version (stripping off version info) showed up as needing update after upgrading Obtainium to v0.8.3-beta. Interestingly enough, Obtainium flagged itself as one of the ones needing update after the v0.8.3 update, adding the Mind giving a tl;dr; of what happened here? Seems like just parsing of version strings, but curious for the highlevel of what happened. |
|
Originally this was only meant to work with Apps that followed a "standard" versioning system, like |
|
Everything should now work fine with the latest version 0.8.4, but I'm leaving this issue open as the current implementation of version detection only works for a minority of Apps. Will continue trying to extend this support. |
|
In the latest update almost everything got fixed, but leaving one behind (in my case). |
|
Obtainium 0.8.4 still presents this issue with: |
|
In 0.8.4, one of my apps is still consistently broken. It doesn't seem to update at all when I press update— the message goes away for a little while, then comes back and its the same:
This doesn't map to the GitHub version name: https://github.com/AnySoftKeyboard/AnySoftKeyboard/releases Thanks for triaging this, btw! It's a fairly serious issue, but these things happen, and I appreciate your work on it. Normalizing GitHub release versions sounds like hard problem. |
|
Just wondering, was the change from the old way of, getting version numbers by downloading the APK, necessary? |
|
I'd agree with S7ven. It seems like the most reliable system would be version number in APK + date of artifact release on GitHub, segmented by if it's flagged as a pre-release. It might save you a lot of headache to just use that, and have the GitHub release title be only on the UI layer. APKs would only need to be downloaded when a new release is cut. GitHub release versions don't seem to follow a consistent pattern from what I've seen. |
|
Yeah I keep finding weird edge cases, and the detection turns out to be broken in the background process (since the plugin doesn't work) which means background update checking might not work right. The issue with using release dates instead of versions is that some sources may not provide release dates - versions are the only thing we can reasonably expect to always have access to. |
|
I meant the date of the github release itself. e.g., for Wikpedia, they use a single release channel called "latest" which they update periodically, but it was updated 12 minutes ago and shows that in the browser (and presumably in the API). The date of the last release could be cached locally, and when the release shows a newer date it could be inferred to be a newer release (which could be confirmed by downloading the APK and looking at I don't know much about android versioning though, so this may not be useful. Thanks for the quick turnaround on all the recent bug fixes! |
|
Right now, all apps from all sources have the same schema and use the same code for update checking, etc. Customizing these things on a per-source basis could get really messy (GitHub may provide release dates/times in the API, but others may not). It's also not clear that using dates would fix anything. The original issue is that when an App version changes externally (the user updates something manually or through an app store), these changes are not picked up by Obtainium which only knows about its own internal versions being tracked. We need a way of converting between the "real" version of a given app (seen in the OS settings) to/from the "fake" version tracked internally by Obtainium; right now that internal version is the version string from the source; I'm not sure how switching to a datetime string would help. |
|
People just shouldn't do updates outside of Obtainium if that's what they're using. 😅 |
|
I have all my apps from github, half of them (about 15) show as having updates available. A fix please, it driving me nuts.
I only update via obtainium. I unistalled the apps (from f-droid) and using obtainium exclusively. |
|
I also had that happen once more with the new version. It's because he switched back to the old method of checking app versions which is less buggy. So it shouldn't happen anymore after this time. |
ImranR98
changed the title
ImranR98
added
enhancement
|
Trying a simpler approach; seems to work fine at least with the Apps mentioned in this thread, but needs more testing. Would appreciate any testing and feedback: app-x86_64-release.zip Note: Remove Obtainium from the Apps list so it doesn't try to downgrade. |
|
No issues with above test version so far |
|
Looks like the above version has issues in the background update checking task. Will look into it later. |
|
Oh yeah, I can confirm I'm probably getting the same behavior |
|
Will test… For now, I have noticed the 'please wait' after download isn't showing anymore… |
The text was updated successfully, but these errors were encountered: