If the code above in the Makefile does not pass our own validation, we should remove it, I find it confusing. Or we can change what was done here: #9413 to put the default into the config file (with a warning) if the version used is not tagged as a release.

I see a few more places where the version is set based on git describe : tools/tm-signer-harness/Makefile, .goreleaser.yml, scripts/dist.ch.

I don't have the full context on this PR; but I'd like to understand the motivation for the change. My impression is that having the git hash in the version is very useful to find out the code behind a log.
For "official" versions, like releases and release candidates, the hash shouldn't be there, but in any other build, I see it of great help.
So, as said above, I'd like to understand the rationale for removing this logic (probably synchronously would be more effective)

Related: #9503.

I'm not convinced though that this PR is the best approach. I agree with @sergio-mena that having the commit hash in the version is useful. The way this is usually handled in semver, however, is to use build metadata.

For example, building off of a tagged commit should produce the version specified in TMCoreSemVer, like v0.38.0-dev.

Building off of a branch or non-tagged commit should produce v0.38.0-dev+ee4023a. The commit hash can simply be obtained from git rev-parse --short HEAD.

Just discussed with @cmwaters synchronously. My understanding is that we agree for the hash to be there (appended at the end) in our "Makefile" when we are "git checked out" on a commit that has no release (or release candidate) tag; and should not be there in any alpha, beta, release candidate, or official release.

ok I've used git rev-parse --short HEAD and appended the commit hash to the end of TMCoreSemVer.

Just as a reminder, this only really affects us, the engineering team, who use the Makefile to build the tendermint binary.