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:

Improve this question
2
  • 2
    Related: softwareengineering.stackexchange.com/questions/341480/…
    – Dan Cornilescu
    Commented Feb 25, 2017 at 4:47
  • Thanks @DanCornilescu. Lie Ryan's suggestion with signing is interesting. I would interpret that as being in the category 'assigning metadata to the package, in order to know what to do with the pre-release metadata in the version'. Ewan's answer is in the category of 're-build and if needed re-test the production package'.
    – Vincent Sels
    Commented Mar 27, 2017 at 13:14

1 Answer 1

Reset to default
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
Improve this answer
6
  • What do you mean with "just add the release tag to the same revision"?
    – Vincent Sels
    Commented Feb 23, 2017 at 9:59
  • Updated the answer
    – marstato
    Commented Feb 23, 2017 at 10:57
  • 1
    Sure, but that doesn't change the version of your package - you'd have to create a new build/package, labeled v1.2, from that tag. You're not deploying the exact package that which was tested and approved to production, but a new one, which might in theory contain something different.
    – Vincent Sels
    Commented Feb 23, 2017 at 12:01
  • There is no solution to this. You cannot have the version name/number within the source and deploy the same revision as two versions.
    – marstato
    Commented Feb 23, 2017 at 12:55
  • Good point. I was actually thinking of scenarios where the version isn't maintained in the source code, but e.g. in the issue tracking / project management tool, like Jira or Mantis.
    – Vincent Sels
    Commented Feb 23, 2017 at 22:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.