CODEWITHSUNDEEP
c#gitversion-controlversioning
Devator
Devator

Reputation: 3904

Software versioning with GIT

I'm writing a software application in C#, currently I'm following the (probably most common) scheme:

Major.Minor.Patch.Revision for example 1.0.5.36182.

For defining if the application is in beta, I simply check for the Patch integer. Is it even? Release. Is it an odd number? Beta.

Git

Now I switched from SVN to Git and want to use commits in my version numbering. Most preferably:

Major.Minor.Patch-commit hash, for example 1.0.5-47ad38f.

The question(s)

Upvotes: 3

Views: 1760

Answers (1)

Chris
Chris

Reputation: 136958

This question is loaded with opinion, but I'll try to help out.

What would be the best way to define my application as beta or just keep using my current method?

I would recommend only tagging non-beta releases, and generating your versions using git describe, e.g. git describe HEAD or git describe some-branch. The output of this command will be something like

  • some-tag, in which case the thing you asked to be described (HEAD or some-branch in this example) corresponds exactly to the tag some-tag, or

  • some-tag-<n>-g<hash>, where <n> corresponds to the number of commits post some-tag and <hash> corresponds to the hash of the commit being described.

    For example, an output of 1.2.3-12-gabcd123 indicates that the described commit is 12 commits after the tag 1.2.3 and has a hash of abcd123.

Under this scheme, versions that output a simple tag like 1.2.3 can be considered stable and ones that are some number of commits away from a tag like 1.2.4-12-gabcd1234 can be considered unstable.

If you require the ability to manually tag non-stable releases, your current technique of using even patch levels for stable and odd patch levels for unstable should work fine, but you may wish to tag those releases with some combination of alpha and beta (or other arbitrary strings) as recommended by semantic versioning. In this case the ordering rules are strictly defined:

Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating the version into major, minor, patch and pre-release identifiers in that order (Build metadata does not figure into precedence). Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: Major, minor, and patch versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version. Example: 1.0.0-alpha < 1.0.0. Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

Is there a way to check for new versions of my application based on the GIT hash?

The output of git describe has the benefit of being alphanumerically sortable as long as your tags are named in a sane way. In the case of semantic versioning, version comparison is defined as above.

If you are tagging unstable patch levels manually and relying on the odd / even distinguisher, comparison becomes trickier. Semantic versioning may be a better bet here, as it has well defined ordering.

"Checking for new versions" is a tricky subject; do you wish to query something like GitHub for new tags and compare them to your current one?

Upvotes: 2

Related Questions