Open smcv opened 1 day ago
@madebr, can you look at this? We should include the git hash in the revision of release archives.
build-release.py
could runbuild-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.
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).
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:In 2.30.8 and 3.1.3, the new Github workflow writes a plain version number like
2.30.8
intoVERSION.txt
, which results in a shorter revision string: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 runbuild-scripts/updaterev.sh --dist
? That's what used to happen with SDL 2 when releases came frommake 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).