6

Semantic versioning encourages using suffixes to indicate pre-releases: alpha, beta or rc builds. Their purpose is well known and documented.

It's also a given that once you create a build or version, its name should not change. All package managers or repositories that I know hence don't support this (NuGet, NPM, Bower).

Isn't that contradictory?

When business or QA approves a certain pre-release build (probably an rc, but maybe even something that you labeled as beta turns out to be production-ready), you can't remove the pre-release tag. And I would assume you don't want to make a whole new build (without a pre-release tag), which might introduce (human) error like accidentally pointing to another commit or revision. To avoid this with certainty, you'd have to re-run it through your DTA street and re-execute acceptance tests.

On a more philosophical note, this seems so contradictory that I don't understand how this notion of prereleases even made it into semver. It seems that this notion of what stage you expect the delivered software to be in should just be metadata, not something to include in the actual version number.

I'm baffled that I can't find practically any discussion on this subject. Doesn't every company which versions and tests its software run into this issue? What am I missing? Or am I just overly concerned about building and re-deploying a final version of the latest approved rc?

Note that I did find these two questions which seem the same, but don't offer clear answers:

Community
  • 1
Vincent Sels
  • 209

1 Answers1

6

First: You dont need to remove the pre-release version. That this very specific revision was a pre-release is a historical fact and i see no good reason to hide that.

Second: just add the release tag to the same revision. If i understand SemVer correctly, that should not be an issue.

Suppose you are using git:

git tag -a v1.2-rc2 9fceb02

Then, when v1.2-rc2 turns out to be production-ready, do

git tag -a v1.2 9fceb02
marstato
  • 4,638