Discussion point; Git tags

Hi!

I found this post by @jzabroski, where he states;

I don’t think tags are a good idea. Next step would be to adopt either GitVersion, GitInfo, or Nerdbank.GitVersioning for predictable, consistent build version numbers. (…)

I’ve got no argument with a .NET-friendly versioning tool being the “go-to”. Or even that it ends up being utilized for that matter.

And even in conjunction with such a tool, I’m unsure why Git tags would be a bad idea?

My thoughts on the matter

There’s absolutely no technical limitations¹ as to what a tag might consist of (the string of it that is). So you may very well have multiple tags pointing at the same commit, like;

• x.y.z-alpha
• x.y.z-beta
• x.y.z-rc1
• x.y.z-rc2
• x.y.z

The idea however, that you (the authors) say²;

We validate **this** specific version (read: commit),
as the one representing the source code,
at a point we'd recommend/want others to use.

is one that I for one would value. This is independent of the versioning scheme (and semantics) that you guys could want/decide upon.

1: In the semantic sense - I guess one could always find some security-hole á la SQL Injection. 2: Through Git’s own tooling - read: tags.

Post-thought addendums

PS: And at no point would I imagine my reasoning/suggestions here to conflict with any preferences of an automated versioning/deploy/integration -tool (as long as you - the users of that tool - are in control of it), and it doesn’t lock down/limit your semantic use of tags.

PPS: For what it’s worth, the above described semantic usage of git tags are also what one of the original, biggest (in open source), and maybe even canonical source code projects - the Linux kernel - itself uses.

[jzabroski]

I started adding git tags since they’re defacto created/maintained when doing GitHub releases.

[x10an14]

Glad to hear I could help/have a potentially positive influence =)