Difference between Verify the 'latest' tag and Retain release order from API

[novocaiin]

Obtainium detects v1.20.0 instead of v1.20.1 as the latest source version for https://github.com/revanced/revanced-manager when using default preferences. Both "Verify the 'latest' tag" and "Retain release order from API" result in Obtainium choosing v1.20.1, but I'm unsure which one I should use. The wiki doesn't seem to mention either preference.

Is "Verify the 'latest' tag" for avoiding pre-release releases?
Does "Retain release order from API" make Obtainium choose whatever is at the top of https://github.com/ReVanced/revanced-manager/releases when I open it in the browser?

[ImranR98]

By default, Obtainium sorts the releases it gets from the GitHub API by release date. The "retain" option prevents this from happening (I don't remember why this was added but there's probably some repo that needs this - you can search for the issue). Note that the API order should be the same as the order you see on the releases page, but I haven't confirmed this.

The "verify latest" option does keep the sorting by release date, with one exception: the release which was marked as "latest" by the developer is always put at the top of the list, even if it isn't the newest release.

Neither of these options have anything to do with prereleases - if "include prereleases" is disabled, those release will be filtered out before any sorting is done.

[ImranR98]

I'd suggest using "verify latest". The only reason it's not on by default is because it sends double the number of requests to GitHub, so people without a GitHub API key would get rate limited twice as fast.

[novocaiin]

By default, Obtainium sorts the releases it gets from the GitHub API by release date.

The "verify latest" option does keep the sorting by release date, with one exception..

So all "verify latest" does is add that exception? Because other than that the behaviors sound the same to me.

v1.20.1 was released a couple hours after v1.20.0. Is the issue that they were released on the same date, which triggers the exception?

[o101010]

Hi,

Maybe it's a change to do ? By default, don't use verify latest if no Github API and enable it if the API is set. And the possibility to overwrite it in specific app configurations with a drop-down menu (default-yes-no)?

[ImranR98]

So all "verify latest" does is add that exception? Because other than that the behaviors sound the same to me.

Yes. When we get an unsorted list of releases from the API, the "verify latest" toggle just moves the one marked "latest" to the top of the list if it wasn't there already.

After that, the list gets sorted by release date unless the "don't sort" toggle is used. This may move the "latest" release back down in some cases, which is why there's no reason to enable both settings at once - you usually need one or the other.