Indicate the version outdated only when it really is

[IncandescentChrysalis]

Issue submitter TODO list

• I've searched for an already existing issues here
• I'm running a supported version of the application which is listed here and the feature is not present there

Is your proposal related to a problem?

No response

Describe the feature you're interested in

Today, when not building the application directly from a release, a warning icon and a message Your app version is outdated. is displayed next to the commit ID having been compiled.

When building from a commit more recent than the latest release, this is wrong and can be confusing for a user, despite the maintainer knowing what they are doing.

The current behaviour merely rely on the latest release API (https://api.github.com/repos/kafbat/kafka-ui/releases/latest) and makes a strict equality comparison between the release tag name and the built version, for instance in ApplicationInfoBuildDTO.isLatestRelease (and maybe somewhere else too?)

The idea here would be to add a few steps to the comparison to decide whether the built version is:

• behind
• identical to
• ahead of

the latest release.

The additional step would be using the GitHub's REST API to compare the latest release and the built version (be it a tag name or a commit ID): https://api.github.com/repos/kafbat/kafka-ui/compare/<latest release tag name>...<built version>
The status field from the answer provides either:

• behind (for instance https://api.github.com/repos/kafbat/kafka-ui/compare/01aa8ab36387c5f1d66d098e71488bfb0eb5f39c...v1.0.0, 01aa8ab36387c5f1d66d098e71488bfb0eb5f39c being the latest commit from main at the moment)
• identical (for instance https://api.github.com/repos/kafbat/kafka-ui/compare/v1.0.0...2956664bd712266f7340659dc9fbb83e6f3f1923, comparing the v1.0.0 tag against its own commit)
• ahead (for instance https://api.github.com/repos/kafbat/kafka-ui/compare/v1.0.0...01aa8ab36387c5f1d66d098e71488bfb0eb5f39c, 01aa8ab36387c5f1d66d098e71488bfb0eb5f39c being the latest commit from main at the moment)

➽ The warning could then only be displayed in the behind case.

Additional/Optional: Maybe another message advising (warning?) to use the release tag in the identical case, if the build version is not exactly the latest release tag name, the comparison being done at the moment.

Describe alternatives you've considered

No response

Version you're running

01aa8ab

Additional context

No response

[Haarolean]

Sounds good. Additionally, we have to still display a warning in case of a diverged branch (having commits not present in our main branch, like here, where one of the commits is from a forked repo)

[IncandescentChrysalis]

Sounds good. Additionally, we have to still display a warning in case of a diverged branch (having commits not present in our main branch, like here, where one of the commits is from a forked repo)
Yet another message I guess, but that is interesting to detect indeed.

I would however not consider this case a warning, as there is little-to-no chance someone would build against something like this by chance, ie without knowing they are trying something special.
Maybe a discreet blue question mark icon (conveying an "unknown/undecidable situation" meaning) would fit this case?

[aguacero7]

I’d like to take care of this. Can you assign it to me?