"Git tag 1.0" results in file version "0.0.0.0"

Version(s)

2.3.0

To reproduce

Steps to reproduce the behavior:

1. Create a git tag 1.0
2. Build Project

Expected behavior

Expect file version to be 1.0.0.0 (default to 0 for any missing version segments)

Actual behaviour

File version is 0.0.0.0

Workarounds

Always tag your repository with {Major}.{Minor}.{Patch}

Additional context

I would expect that creating a tag of just 1 should default a file version of 1.0.0.0

[bartelink]

While I appreciate the spirit of the suggestions and the seconding thereof, I believe Adam’s stance is absolutely correct; though I’d like to add some further reasons…

Tags added by developers, and specific version suffixes etc feed into file names with wide-ranging implications. For instance, I’ve seen MinVer used as a commandline tool in repos where there’s lots of legacy tags of various forms Being tolerant of (and then needing to document the supported) permutations of aliases of equivalent versions would cause far more problems that it would solve.

[ghorsey]

What I was trying to say (obviously not well after a couple of drinks😁) is that a large audience for your component is going to be people, like myself, using this awesome component, manually tagging commits. Since it derives versions from git tags, I think any reasonable person would expect the tag 1.0 would derive the file version 1.0.0.0 and not 0.0.0.0, which is what felt like a bug or a gap since the result lost information.

I understand the semantics of saying 2.0 is inaccurate when meaning 2.x when dealing with version ranges, but this isn’t about ranges, its about deriving version numbers from tags.

The point software being a human effort is that often times we write component to be used by other developers vs components to be used by other components. So I think considering that audience, especially when they are either end users (obviously) or other developers, and setting reasonable defaults goes a long way for these components we write just working under broad circumstances. Maybe this is just my odd philosophy on software development and various aspects that I find important.