AppImage: Mumble continuous release lacks good version information

[TheAssassin]

#3703 didn't introduce proper versioning, now the "snapshots" have only the commit, which is bad since they're cryptic and don't provide any information on when they have been built or which version is newer. That way, those snapshots are pretty useless for daily use. Please fix that by providing some real version number. Git commits are no version information usable to the average user.

CC @davidebeatrici

[probonopd]

The 7-digit git has unquestionably links the continuous build to the matching source code, which can easily be retrieved (or even linked to) using this hash.

"Real version numbers" only exist for releases as far as I know.

What would you propose instead?

[TheAssassin]

Your entire comment doesn't even try to answer the issue I opened. It tries to justify using commit hashes as version numbers. But they're not numbers, they're IDs. Nobody ever stated to use these as version numbers for use by end users.

Ever tried git describe --tags? That gives you the name of the latest tag, the offset from there (count of commits) and the commit hash. If you have to consecutive builds, you can clearly see where approximately this sorts in (as in "must be after that tag"), which one is newer (comparing the offsets) and also links to the commit.

Commit IDs are not version numbers! They shall not be used solely.

[probonopd]

A version is just a string, anyway ;-)

[TheAssassin]

Maybe technically, but not semantically. If you compare "abcdefg" vs. "1.0.0", there's a big semantic difference in there. Your shibboleth tries to understate the importance of good version numbering, but users highly appreciate those. A technically better implementation is available, too, so there's no reason not to do that.

[davidebeatrici]

For reference, the script we use to generate the release name can be found here: https://github.com/mumble-voip/mumble-releng/blob/753ee8c3881ed3bd6fe5ff3470da01bf9577a3cb/tools/mumble-version.py

I propose to use the same scheme we use for the snapshots, replacing snapshot with continuous.

[TheAssassin]

You can also call it "snapshot", I guess.

[davidebeatrici]

I agree.

[Kissaki]

@TheAssassin You know it would be nice if you would make your points a less aggressive and dismissive way. How you presented your argument is very hyperbolic to the point of being wrong, and initially confusing as well. You’re not entitled to your subjective desires on this free software project. Using kindness and thoughtful argumentation instead of aggression would be appreciated.

Anyway. I mentioned this to davide elsewhere, I am strongly against using a different name for these development snapshots. Introducing another label for them is just confusing to users. We have always labeled them development snapshots, and so they should also be labeled so in this "continuous release" AppImage. That will also make it a bit clearer that these are not necessarily stable releases intended for every end user.

As for the argumentation of version number versus commit hash: Yes, we should probably use the same versioning label that we use for our development snapshots.