Can Git Tag Versions Used for Software Promotion via Releases Be Deleted? (Edited)

I realized that in my case, pre-release tags are not needed, and now I can safely delete them.

Using build metadata is also interesting to implement in my project; I will work on this further.

Thank you for your help!

There should be a clear version and artifact management strategy.

Use main versioning (major, minor, patch) for changes related to the software's code and configuration, and use build metadata for information about the build process and artifacts (e.g., build number, commit hash, build script version). This way, pre-release tags can be easily deleted while keeping final versions for reproducibility.

In the context of Semantic Versioning (SemVer), you can use build metadata to avoid confusion with pre-release versions. In SemVer, you can add metadata to the version using the + symbol, for example: v1.9.4+001. This does not affect the version priority but allows you to record build information.

Thus, instead of using pre-release tags, you can record packaging changes in metadata, such as build number or commit hash, which allows maintaining version transparency and avoids the need to delete tags.

Deleting Git tags that represent pre-release versions of software is acceptable if you clearly define which versions need to be retained.

In corporate environments, there may be different version retention policies to ensure the ability to reproduce versions released to production.

If your goal is to support reproducibility only for final versions, intermediate tags like beta or release candidate can be easily deleted after releasing the final version.

However, if test or beta versions are important for subsequent debugging or auditing, then of course, they should be preserved.