htop --version output is strange on git checkout

[rubyFeedback]

Hello htop devs,

I just git cloned htop, aka today, and compiled it. It all works fine too on my Linux machine. \o/

However had, when I run this:

htop --version

I get the following output:

htop 3.4.0-dev-3.3.0-269-g899c6b6

I believe the prior output from stable htop, was simply that:

htop 3.3.0

I assume the trailing part is some internal hash git may use or so, but what I find confusing is that in the above output of the git checkout, we see two version strings:

htop 3.4.0-dev-3.3.0

Aka both 3.4.0 and 3.3.0.

I also compile mpv from git sources and it has output such as this:

 mpv v0.39.0-758-gf385a6b25 

So, also that strange trailing hash part, but more importantly, the version only once, aka 0.39.0. So I think htop may be a bit too eager in regards to showing version output.

This is not really very important :) but I actually do batch-query all locally installed versions of programs, and then use that to compare to a database of programs that could be upgraded, so if at all possible, I think simplifying this to just one version would be better. I guess at the least the "3.3.0" string there should not be shown, if the first reported version in the String is 3.4.0 (aka different).

[BenBE]

The version number is in multiple parts, with 3.4.0-dev being the development version, i.e. where things are going towards; and 3.3.0-269-g899c6b6, which is 3.3.0 (most recent tag before this version), 269 (number of commits since than) and 899c6b6 (the commit you are compiling).

The format is intentional, although ~ for splitting would be preferred.

FWIW, output by normal release versions will remain simply 3.4.0.

[Explorer09]

[...] when I run this:

htop --version

I get the following output:

htop 3.4.0-dev-3.3.0-269-g899c6b6

I assume the trailing part is some internal hash git may use or so, but what I find confusing is that in the above output of the git checkout, we see two version strings:

htop 3.4.0-dev-3.3.0

Aka both 3.4.0 and 3.3.0.

I mentioned this issue before when the version string change was being merged. For me, the two version numbers surely look like a bug (the git describe output wasn't tuned properly), but fortunately this only affects the development versions and never the release versions.