Jamulus: Version number of unreleased version

[fleutot]

Version numbering for untagged commits creates confusion. People see 3.5.9git and wonder where they can get version 3.5.9, before it is released.

Suggestion: use the git describe --long --tags --dirty --always
See here

The result of this command can be used in a makefile to define a C macro (to pass to gcc with - D), which generates a relevant version number everytime you run make.

The result is:

<last tag>[-g<SHA1>][-dirty]

, or something along that line. Last tag is used, instead of upcoming version.

If another commit is checked out, you know which one. If there are local changes for that build, you know that too.

If that looks like a good idea, I can work on that next week.

[pljones]

I was thinking along these lines (I think there may be another issue that mentioned it in passing?). I do agree it would cut the confusion.

[fleutot]

@pljones we had that discussion in the Facebook group.

[corrados]

I don‘t think we need a complicated versioning. If 3.5.10git is confusing, I could use the last version instead: 3.5.9git

[fleutot]

How do you update to *.*.*git? Manually? The described scheme is not that complex, once implemented everything happens automatically.

[corrados]

I only update it once I make a new release and keep it in sync with the ChangeLog.

[corrados]

I have now changed the version number from 3.5.10git to 3.5.9git. I'll do this strategy for the next versions, too. I'll close this Issue now. If the confusion will not be solved by this, just re-open this issue again or create a new one.

[storeilly]

Would it be possible to include optional, detailed commit id's in the project file? It would help to identify exe's where there are multiple versions undergoing testing. I have the following in my Jamulus.pro file which might help. It only affects the make when I include "versionifo" in the config string.

================================================
VERSION = 3.5.12git

use target name which does not use a capital letter at the beginning

contains(CONFIG, "noupcasename") {
message(The target name is jamulus instead of Jamulus.)
TARGET = jamulus
}

allow detailed version info in target executable

contains(CONFIG, "versioninfo") {
message(Using custom target and version)
GIT_CURRENT_SHA1=$$system(git describe --tags)
VERSION = $$VERSION-$$GIT_CURRENT_SHA1
TARGET = $$TARGET-$$VERSION
message(Version is $$VERSION)
message(Target is $$TARGET)
}

CONFIG += qt \
thread \
release

etc....

[fleutot]

@storeilly Note that what you'd get in GIT_CURRENT_SHA1 is not a SHA1, so the variable name is misleading.

Also, you might want to include --dirty to show that the build had local changes.

--always is a nice fallback to have if no tag was found.

As per my initial post, I still don't see why this wouldn't be the versioning by default. It doesn't cost, it's automatic, it's human readable, it removes ambiguity.

[storeilly]

I've had issues with the length of this so have switched to using this.... it's much shorter.

================================================

allow detailed version info in target executable

contains(CONFIG, "versioninfo") {
message(Using custom target and version)
GIT_HASH=$$system(git rev-parse --short HEAD)
VERSION = "$$VERSION".$$GIT_HASH
TARGET = "$$TARGET".$$VERSION
message(Version is $$VERSION)
}
message(Target name is $$TARGET)