Versioning Conventions

All builds on the same branch as the last vLast will have the format:

{NextSemVer}+{commitsSince_vLast}

For example, if I tag a release 0.2.0 (so the tag is on the HEAD of master) and I merge a pull request with 2 commits then the build number will be: 0.2.1+003.

This convention gives you a number of advantages:

• You can use continuous delivery with the trigger of a version bump being after the build (say when you decide to promote to production) without having to re-build the software (thus following the principle of compiling once and using that result throughout the rest of the deployment pipeline).
  • This is because the build metadata has no semantic meaning so 0.2.1+003 is the same semantic version as 0.2.1+234 - thus you can decide to deploy the software at any time and your semantic version number will have increased by one increment only (thus conforming to SemVer rules)
• You have a unique build identifier for every push to master
• You are not relying on the CI server to generate your unique identifier - you can completely rebuild the CI server and point it at a commit and it will generate the same build identifier (i.e. it's idempotent)
• All versioning information is kept in source control
• You get an indication of how long it has been since you last released (in terms of number of commits), which provides a handy hint to encourage you to release more often (when the number gets higher your confidence level about whether there is a bug in the release decreases)

For situations where you need a four part version number there is a four part variable exposed by GitHubFlowVersion that uses the number of commits as a fourth number rather than metadata, e.g. 0.2.1.3 - see below for the variable name.