4

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:

  • 2
  • 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 Mar 27 '17 at 13:14
3

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
  • What do you mean with "just add the release tag to the same revision"? – Vincent Sels Feb 23 '17 at 9:59
  • Updated the answer – marstato Feb 23 '17 at 10:57
  • 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 Feb 23 '17 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 Feb 23 '17 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 Feb 23 '17 at 22:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.