Should VERSION.txt in tarballs include the git sha1?

[smcv]

Before 2.30.8 and 3.1.3, the SDL_REVISION would have a git sha1 and a reference to a tag in it, even in release tarballs. For example, Ubuntu 24.04 has SDL 2.30.0, and adds vendor-specific info (SDL_VENDOR_INFO) in parentheses:

ubuntu-24.04$ strings /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0|grep SDL-
SDL-release-2.30.0-0-g859844eae (Ubuntu 2.30.0+dfsg-1build3)

In 2.30.8 and 3.1.3, the new Github workflow writes a plain version number like 2.30.8 into VERSION.txt, which results in a shorter revision string:

debian-unstable$ strings /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0|grep SDL-
SDL-2.30.8 (Debian 2.30.8+dfsg-1)

Is this working as desired? It means that if for whatever reason we build more than one tarball that claims to be the same version (like the 3.1.3 release-candidate that I packaged at the end of last week, and the final 3.1.3 release), they are indistinguishable, and that seems maybe bad.

If we want the longer names back, build-release.py could run build-scripts/updaterev.sh --dist? That's what used to happen with SDL 2 when releases came from make dist with Autotools. For best results it would need to stop doing such a shallow git clone, so that for release candidates, it can see back in history as far as at least the previous tag (and for the final release, it would need to be run with the tag already created and available).

[slouken]

@madebr, can you look at this? We should include the git hash in the revision of release archives.

[smcv]

build-release.py could run build-scripts/updaterev.sh --dist

This also overwrites include/SDL3/SDL_revision.h with a header that hard-codes the version number, which if I remember correctly is done for the benefit of non-CMake builds, e.g. unpacking the tarball and building directly from it with something like MSVC.

[smcv]

Relatedly, is SDL_REVISION_SUFFIX necessary? It seems redundant with SDL_VENDOR_INFO (which is the Ubuntu 2.30.0+dfsg-1build3 or Debian 2.30.8+dfsg-1 part of my examples).