[0.8] Release tarball lacks hardcoded version 0.8, ends up with #define VERSION ""

[hartwork]

After running configure with the 0.8 release tarball, I end up with #define VERSION "" in ./src/config.h rather than #define VERSION "0.8". So it seems broken, is that known?

$ wget https://github.com/FreeSpacenav/spacenavd/releases/download/v0.8/spacenavd-0.8.tar.gz
$ tar xf spacenavd-0.8.tar.gz
$ cd spacenavd-0.8/
$ ./configure 
fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
configuring spacenavd - 
  prefix: /usr/local
  optimize for speed: yes
  include debugging symbols: yes
  x11 communication method: yes
  use hotplug: yes

creating Makefile ...
creating config.h

Done. You can now type make (or gmake) to compile spacenavd.

$ fgrep VERSION src/config.h 
#define VERSION ""

PS: My downstream patch for Gentoo: https://github.com/gentoo/gentoo/blob/26495d73d0c146733900ff66be3031fe364ad194/app-misc/spacenavd/files/spacenavd-0.8-version.patch

[jtsiomb]

I need to come up with a scheme that works outside of the git repo too. Maybe if git returns an error code, it should try to use the part of the current directory after spacenavd- as a version string.

I don't think this is important enough to warrant a bugfix 8.1 release. The version is only used in the logfiles. But I'll try to remember to fix this before the next release.

[hartwork]

I need to come up with a scheme that works outside of the git repo too. Maybe if git returns an error code, it should try to use the part of the current directory after spacenavd- as a version string.

The rest of the world hardcodes versions in the code at one place, ideally only one. Why does that need to be avoided at high cost?

The version is only used in the logfiles.

Doesn't seem true to me:

# spacenavd -version  # with my Gentoo patch
spacenavd 0.8

[jtsiomb]

Because it's almost guaranteed that I'll forget to change the hardcoded version number when it's time for the next release.

[hartwork]

Why guaranteed? That approach seems to work well 99% of the time for many other projects. The more releases you do, the more of a habit bumping versions before releases becomes. No?

[jtsiomb]

No.

[hartwork]

Why no?

[jtsiomb]

fixed in revision d3a3aa0