The v prefix really helps us only run ci on version tags instead of random tags as well. If you are strict and always use semantic versions for tags, you can just keep doing what you are doing. But if you ever want to create some random tag later and don't want your automation to try to use it as a version number, the v prefix helps.

How is the version information included in the software if you don't include it in the source? Do you have a deploy script that modifies source based on the git tag, or ?

I sometimes dump git describe to a JSON file rather than modifying a source file and let the build bundle it as an embedded resource. You can .gitignore the JSON file to keep it from accidentally getting checked in (and causing merge conflicts).

As also pointed out, many build tools that want or need version numbers often also have command line flags or can take environment variables instead of using source files.

There seems a lot to like about that approach.

Some languages and build systems also allow you to set constants from compiler flags (Go for example). Other systems make the entire build configuration an executable program (Gradle).

I did not know that. I mostly use interpreted languages (Python, JavaScript, etc.)

For Python there are tools like setuptools_scm to completely automate the setup of this.

Good to know.

The build process uses the tag.

In practice that's a tiny bit more complicated to do it really well, with the version as a dependency in the build process. When developing, you don't want to trigger a full rebuild if the version number changes, but you do have rebuilds to do when it does.