Refined-github: Old git tag is displayed when there's newer one

[vanniktech]

In the given repository - https://github.com/trello/navi there are different tags. The old tags follow the x.y.z convention. Currently the latest one there being displayed with refined github is 0.2.2.

However there's a newer version 2.0 as well as 1.0. From a user perspective even though the versioning might not be consistent I'd expect to get 2.0 displayed as the current tag.

I understand that semver is used in refined github. Is there another API that we can use to fix this behavior or should this get reported to semver?

[busches]

You can try and report it to semver as it's currently saying v2.0 is not valid semver, which it's not. Your other alternative is to convince Sindre to use a different semver parsing library in to-semver, but I doubt that'll happen either.

The easiest option is to have them tag their releases using proper semver.

[jdreesen]

I have the same problem here: https://github.com/izhangzhihao/intellij-rainbow-brackets

[vanniktech]

I agree that it would be best to stick to semver where applicable although everyone is brewing their own beer. I feel like it's best to be lenient and support more than what was meant to be used in case it improves the end result - which it does in those cases.

[busches]

@jdreesen that's 100% the same issue, the new releases are not following semver, so they are ignored. Semver requires a major.minor.patch version, the new releases do not have a patch version.
See here for more information on SemVer - https://semver.org/

[fregante]

Somewhere (either here or in to-semver), the version could be normalized by adding .0 before being passed to node-semver

[nschloe]

A similar thing happens for https://github.com/live-clones/recalbox:

• Latest release: 18.04.20
• Displayed by github-refined as latest: 17.11.10

[fregante]

Perhaps we can just parse and sort the versions in-house. This may include betas but it would give us more flexibility and support non-semver-compliant versions (common outside the js world)

[jbtule]

Github says latest release is v4.0.3.130 which is correct.
https://github.com/fsprojects/FSharp.Interop.Dynamic/releases

Github refined says latest release is v4.0.3-beta95 not correct.
https://github.com/fsprojects/FSharp.Interop.Dynamic

[2m]

Another data point: https://github.com/akka/reactive-kafka

Latest release tag is v0.20, Github Refined reports v0.10.1 as the latest one.

[pendowski]

I'm not going to add another example since we know what seems to be the problem.
Personally, I think that if someone wants different versioning system it's their choice and it's definitely not Refined Github's user fault - there's no need to force that.

An alternative could be to just not display the newest release if the newest one wasn't validated by semver library - removing the button completely or making it a link to Releases.

Either one of those options is better than pointing potentially to the wrong release.

[vanniktech]

I still favor of being lenient and respecting that some just don't follow semversions. Google for instance never does this for their Java libraries (e.g. Dagger / Truth / Robolectric). They've also got it defined somewhere.

We can all be just a bit more graceful and show the correct thing - since we know 2.18 is superiors than 2.0.0

[fregante]

Try PR #1328, it should work on all the repos mentioned here. Please report more if there are some version formats I didn't think of

[salmanulfarzy]

| | tag displayed | latest release |
|:----:|:-----------------:|:-----------:|
| hub | v2.3.0-pre10 | hub 2.3.0 – codename “Ancient Psychic Tandem War Elephant”

[jdreesen]

  | tag displayed | latest release
-- | -- | --
https://github.com/symfony/symfony-docs | vPR3 | v2.3.4

[fregante]

The hell is vPR? 😳 😅

You can open further issues on https://github.com/bfred-it/tiny-version-compare

_Edit: fixed all in [email protected]_