<p>It should be fine to delete git tags that represent pre-release versions of software as long as you clearly define what you mean. For example, in corporate settings, you often face record retention policies and the need to ensure the reproducibility of versions. But what versions need to be able to be reproduced? For a SaaS provider, the obvious answer would be that you need to reproduce any version that ends up in production. But what about other customer-facing pre-production or UAT environments? Maybe those, too. For someone releasing packaged software, does it include internal testing versions? Or does it extend to versions made available through opt-in, such as beta or canary channels? Or only the final version made generally available? Once you know which versions you'd need to be able to reproduce, you'd know which tags you would need to maintain and which could be deleted.</p>
<p>In the Semantic Versioning context, though, you're missing the build metadata attribute.</p>
<p>SemVer contains definitions of both pre-release versions (which are denoted by a hyphen and dot-separated identifiers following the patch version) and build metadata (denoted by appending a plus sign and dot-separated identifiers following either the patch version or the pre-release version. This leads to a full format of <code>MAJOR.MINOR.PATCH{-PRERELEASE}{+BUILDMETADATA}</code>.</p>
<p>I wouldn't use pre-release versions to track changes in packaging. Instead, I'd use build metadata. I would not be surprised by code and configuration changes between <code>1.10.3-1</code> and <code>1.10.3-2</code>. Of course, that doesn't necessarily mean that there will be code and configuration changes. The SemVer spec says that build metadata is ignored when determining precedence.</p>
<p>There is a potential for confusion here. Let's say that you release <code>1.10.3+001</code>. Then, you notice a packaging error that doesn't affect your versioned elements. Your next version would be <code>1.10.3+002</code> if you use an autoincrementing build metadata. However, any tooling following the spec would ignore the metadata. The correct thing to do would be to remove <code>1.10.3+001</code> from wherever you store your packages for deployment or download. When you deploy <code>1.10.3</code>, the only matching package would be <code>1.10.3+002</code>. If both exist, there is an opportunity for ambiguity that SemVer does not address and different tools implementing SemVer could resolve it differently.</p>
<p>This boils down to a simple explanation:</p>
<ol>
<li>Use SemVer's major, minor, patch, and pre-release versioning to identify changes to the versioned package (considering both code and configuration files). Use the build metadata to capture information about your build pipeline (things like the target operating system, the version of your pipeline scripts, the git tag built, an autoincrementing counter for the pipeline execution, a timestamp of the build, and so on).</li>
<li>Clearly define a records retention and configuration management strategy so you know what you need to retain. Ensure your git tags, build artifact repository, CI pipeline, and other tools support this strategy.</li>
</ol>

CC BY-SA 4.0
2024-10-12T16:32:25.393Z
Thanks for confirming my thoughts around the validity of deleting pre-release tags. Yes, of course corporate policy ultimately dictates whether that's possible. And in my environment, because we don't do proper promotioning, we keep _everything_, which gets expensive with storage space. But we're only required to keep whatever has been deployed to production. As far as the build metadata portion of SemVer, I didn't mention it because it plays _no part_ in determining whether a package is newer/older than another package. So that doesn't quite work. (Cont'd)
fourpastmidnight
CC BY-SA 4.0
2024-10-12T16:34:06.033Z
Often times, you see people releasing v1.10.3-beta, or `-alpha` or `-rc`, etc., and that communicates intent--this is not technically stable and may even be unsupported. The metadata tag I plan to use to record information like the git sha that resulted in the build, as well as the build id to tie the package to a specific build. Once again, thank you for your answer, I appreciate the time you took to write it.
fourpastmidnight
CC BY-SA 4.0
2024-10-12T16:36:58.520Z
Sorry, I missed the part where you mentioned that build metadata doesn't affect ordering. And I understand what you were saying. I'd like to make packaging errors more explicit by releasing a new, unambiguously versioned package. Like I wrote in my question, I consider the package version to be different than the software version, even if 99% of the time they end up being the same. But nothing says the need to be the same. They are two different things. One is the software, the other is the distribution container. Thanks again for your well-thought out reply.
fourpastmidnight
CC BY-SA 4.0
2024-10-12T13:03:50.550Z
2024-10-12T13:03:50.550Z
Thomas Owens
<p>I wonder if anyone has any experience to help me understand if it's acceptable to delete git tags that represent pre-release versions of your software. Before anyone provides a knee-jerk reactive answer to my question, please read the situation below.</p>
<p>For background, I'm using GitVersion to calculate my software version. I want to promote my distribution artifacts <em>without</em> rebuilding the software to simply produce the distribution artifact.</p>
<p>One of the frictions I'm rubbing up against with versioning is that a lot of the tooling out there doesn't really separate the version of the software from the version of the distribution mechanism, i.e., a Nuget package. For simple software the versions of the softawre and the package its distributed in will often be the same.</p>
<p>But the version of the software is <strong>NOT</strong> the same as the version of the distribution package. 99/100 times, these <em>will</em> be the same—but they don't have to be. For example, suppose there's an error in how the package was constructed? Do you rebuild the (already) tested software just to repackage it due to a packaging error? Why? There's nothing wrong with software v1.10.3 being in a distribution package of v1.10.4. (I like that in the Linux world, they have version numbers like 1.10.3-1, indicating that this is the first package release of v1.10.3; and if there was a packaging error or something else changed about the package but the built software is unaffected, they just release 1.10.3-2. Unfortunately, for SemVer, that <code>-1</code> or <code>-2</code> would automatically make the package a &quot;pre-release&quot; package, and for some, policies dictate that pre-release versions of software should not be used. Version numbers <em>communicate</em> something, and when you use SemVer, you're communicating something specifc, so...  )</p>
<p>That's just one place where there's friction. The other more notable place is in terms of software promotion. So, let's say you're developing <code>v1.10.3</code> of your software. You think it's good to go, so you want to release a beta package of the software. Now, you've already built <code>v1.10.3</code>. You may have some internal packages, e.g. <code>v1.10.3-ci.0001</code>, <code>v1.10.3-ci.0002</code>, etc. So now you want to release it as beta. Do you rebuild? Why would you? You already internally tested everything. Rebuilding means you're deploying <em>untested</em> software (untested in terms of any manual QA testing that was done, not unit/integration/e2e or other automated testing—and not everyone has completely automated testing). I mean, sure, the software <em>should</em> be the same, but it's not an ironclad guarantee that it will be. (Stranger things have happened—a cosmic ray hitting the build server at just the right time!) Anyway, let's just be very pessimistic here. The point is, you've already built the software, you don't need to build it again.</p>
<p>So my idea is to just add a tag at the commit: <code>v1.10.3-beta.0</code>. Since GitVersion defaults to using the <em>highest</em> version tag at a given commit, this should work. (And yes, I realize that <code>beta</code> comes <em>before</em> <code>ci</code>, which means that <code>beta</code> would be considered a <em>lower</em> version than a <code>ci</code> version—I was just using an example. One would need to <em>carefully</em> choose their pre-release tags; but that's true no matter what.)</p>
<p>And now I come to the point and my ultimate question: Is it OK to delete any of these git tags. Let's say I have a string of awesome code writing luck: I  commit a change that calculates to <code>v1.10.3</code>. A CI build is produced with some version that would be lower than a potential beta release. That same commit is beta quality, so I git tag the commit with <code>v1.10.3-beta.0</code>. Oops, package error, re-tag the commit <code>v1.10.3-beta.1</code>. As fortune would have it, it's potentially releasable, so tag the commit again: <code>v1.10.3-rc.0</code>. And luck strikes again, it's ready to go: tag the commit again, <code>v1.10.3</code>. So our commit graph looks like this:</p>
<pre><code>$ git log --one-line -n1 --decorate
* abc123def (tag:v1.10.3-beta.0, tag:v1.10.3-beta.1, tag:v1.10.3-rc.0, tag:v1.10.3, master, origin/master) feat: My awesome feature
</code></pre>
<p>Now that I've released <code>v1.10.3</code>, is it OK or even recommended to delete tags <code>v1.10.3-beat.0</code>, <code>v1.10.3-beta.1</code> and <code>v1.10.3-rc.0</code>?</p>

<versioning>
Is it ever OK to delete Git version tags used for promoting software through the release process?
fourpastmidnight
# Is it ever OK to delete Git version tags used for promoting software through the release process?

(Asked by: username_0 on 2024-10-12)

I wonder if anyone has any experience to help me understand if it's acceptable to delete git tags that represent pre-release versions of your software. Before anyone provides a knee-jerk reactive answer to my question, please read the situation below.
For background, I'm using GitVersion to calculate my software version. I want to promote my distribution artifacts without rebuilding the software to simply produce the distribution artifact.
One of the frictions I'm rubbing up against with versioning is that a lot of the tooling out there doesn't really separate the version of the software from the version of the distribution mechanism, i.e., a Nuget package. For simple software the versions of the softawre and the package its distributed in will often be the same.
But the version of the software is NOT the same as the version of the distribution package. 99/100 times, these will be the same—but they don't have to be. For example, suppose there's an error in how the package was constructed? Do you rebuild the (already) tested software just to repackage it due to a packaging error? Why? There's nothing wrong with software v1.10.3 being in a distribution package of v1.10.4. (I like that in the Linux world, they have version numbers like 1.10.3-1, indicating that this is the first package release of v1.10.3; and if there was a packaging error or something else changed about the package but the built software is unaffected, they just release 1.10.3-2. Unfortunately, for SemVer, that -1 or -2 would automatically make the package a "pre-release" package, and for some, policies dictate that pre-release versions of software should not be used. Version numbers communicate something, and when you use SemVer, you're communicating something specifc, so...  )
That's just one place where there's friction. The other more notable place is in terms of software promotion. So, let's say you're developing v1.10.3 of your software. You think it's good to go, so you want to release a beta package of the software. Now, you've already built v1.10.3. You may have some internal packages, e.g. v1.10.3-ci.0001, v1.10.3-ci.0002, etc. So now you want to release it as beta. Do you rebuild? Why would you? You already internally tested everything. Rebuilding means you're deploying untested software (untested in terms of any manual QA testing that was done, not unit/integration/e2e or other automated testing—and not everyone has completely automated testing). I mean, sure, the software should be the same, but it's not an ironclad guarantee that it will be. (Stranger things have happened—a cosmic ray hitting the build server at just the right time!) Anyway, let's just be very pessimistic here. The point is, you've already built the software, you don't need to build it again.
So my idea is to just add a tag at the commit: v1.10.3-beta.0. Since GitVersion defaults to using the highest version tag at a given commit, this should work. (And yes, I realize that beta comes before ci, which means that beta would be considered a lower version than a ci version—I was just using an example. One would need to carefully choose their pre-release tags; but that's true no matter what.)
And now I come to the point and my ultimate question: Is it OK to delete any of these git tags. Let's say I have a string of awesome code writing luck: I  commit a change that calculates to v1.10.3. A CI build is produced with some version that would be lower than a potential beta release. That same commit is beta quality, so I git tag the commit with v1.10.3-beta.0. Oops, package error, re-tag the commit v1.10.3-beta.1. As fortune would have it, it's potentially releasable, so tag the commit again: v1.10.3-rc.0. And luck strikes again, it's ready to go: tag the commit again, v1.10.3. So our commit graph looks like this:
$ git log --one-line -n1 --decorate
* abc123def (tag:v1.10.3-beta.0, tag:v1.10.3-beta.1, tag:v1.10.3-rc.0, tag:v1.10.3, master, origin/master) feat: My awesome feature

Now that I've released v1.10.3, is it OK or even recommended to delete tags v1.10.3-beat.0, v1.10.3-beta.1 and v1.10.3-rc.0?

**Tags:** versioning


---

## 1 answers

### Answer by username_1 on 2024-10-12. Score: 2 | Accepted answer

It should be fine to delete git tags that represent pre-release versions of software as long as you clearly define what you mean. For example, in corporate settings, you often face record retention policies and the need to ensure the reproducibility of versions. But what versions need to be able to be reproduced? For a SaaS provider, the obvious answer would be that you need to reproduce any version that ends up in production. But what about other customer-facing pre-production or UAT environments? Maybe those, too. For someone releasing packaged software, does it include internal testing versions? Or does it extend to versions made available through opt-in, such as beta or canary channels? Or only the final version made generally available? Once you know which versions you'd need to be able to reproduce, you'd know which tags you would need to maintain and which could be deleted.

In the Semantic Versioning context, though, you're missing the build metadata attribute.

SemVer contains definitions of both pre-release versions (which are denoted by a hyphen and dot-separated identifiers following the patch version) and build metadata (denoted by appending a plus sign and dot-separated identifiers following either the patch version or the pre-release version. This leads to a full format of `MAJOR.MINOR.PATCH{-PRERELEASE}{+BUILDMETADATA}`.

I wouldn't use pre-release versions to track changes in packaging. Instead, I'd use build metadata. I would not be surprised by code and configuration changes between `1.10.3-1` and `1.10.3-2`. Of course, that doesn't necessarily mean that there will be code and configuration changes. The SemVer spec says that build metadata is ignored when determining precedence.

There is a potential for confusion here. Let's say that you release `1.10.3+001`. Then, you notice a packaging error that doesn't affect your versioned elements. Your next version would be `1.10.3+002` if you use an autoincrementing build metadata. However, any tooling following the spec would ignore the metadata. The correct thing to do would be to remove `1.10.3+001` from wherever you store your packages for deployment or download. When you deploy `1.10.3`, the only matching package would be `1.10.3+002`. If both exist, there is an opportunity for ambiguity that SemVer does not address and different tools implementing SemVer could resolve it differently.

This boils down to a simple explanation:

1. Use SemVer's major, minor, patch, and pre-release versioning to identify changes to the versioned package (considering both code and configuration files). Use the build metadata to capture information about your build pipeline (things like the target operating system, the version of your pipeline scripts, the git tag built, an autoincrementing counter for the pipeline execution, a timestamp of the build, and so on).
2. Clearly define a records retention and configuration management strategy so you know what you need to retain. Ensure your git tags, build artifact repository, CI pipeline, and other tools support this strategy.

> **Comments:**
> **username_0**: Thanks for confirming my thoughts around the validity of deleting pre-release tags. Yes, of course corporate policy ultimately dictates whether that's possible. And in my environment, because we don't do proper promotioning, we keep _everything_, which gets expensive with storage space. But we're only required to keep whatever has been deployed to production. As far as the build metadata portion of SemVer, I didn't mention it because it plays _no part_ in determining whether a package is newer/older than another package. So that doesn't quite work. (Cont'd)  
> **username_0**: Often times, you see people releasing v1.10.3-beta, or `-alpha` or `-rc`, etc., and that communicates intent--this is not technically stable and may even be unsupported. The metadata tag I plan to use to record information like the git sha that resulted in the build, as well as the build id to tie the package to a specific build. Once again, thank you for your answer, I appreciate the time you took to write it.  
> **username_0**: Sorry, I missed the part where you mentioned that build metadata doesn't affect ordering. And I understand what you were saying. I'd like to make packaging errors more explicit by releasing a new, unambiguously versioned package. Like I wrote in my question, I consider the package version to be different than the software version, even if 99% of the time they end up being the same. But nothing says the need to be the same. They are two different things. One is the software, the other is the distribution container. Thanks again for your well-thought out reply.  

---

