PATCH version is set to 1 instead of 0

[alexzaitzev]

When MAJOR or MINOR is increased PATCH version is set to 1 and not to 0 as SemVer says:

https://semver.org/#spec-item-7

7. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

https://semver.org/#spec-item-8

8. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY also include minor and patch level changes. Patch and minor versions MUST be reset to 0 when major version is incremented.

[AArnott]

I guess you could say we do set it to one. And then we start counting commits and find one, so we set the version height to 1 to match. SemVer also probably was written with the idea in mind that people manually increment the number with each release, such that patch goes from 0 to 1 to 2 with each release. We don't do that either, since NB.GV goes up implicitly with each commit.
At the moment, it's actually mildly useful that we 'start a 1' because we in fact start at 0, but you only see it before you commit the change. So when you see a value of 0 you know you've changed the version but haven't committed it yet.
Even if we started at 0, once you merge this change into your main branch (possibly via pull request), that's one more commit and it'll be +1 anyway.

In summary: when you're setting PATCH with commit counts, it's really hard (and kinda pointless) to have your actual next release be any particular number, let alone 0.

But if you really care about version numbers for branding purposes, you can set version: "2.3.0" in your version.json file, and the commit height then moves to 4th position. That's also semver v2 non-compliant, but it's hidden by default from nuget package versions.

[alexzaitzev]

I understand the idea of counting versions height. And 1 in that case is natural (height can't be 0), but then I see here a leaked abstraction, because an implementation detail (git height) affects contract (SemVer). It doesn't matter how we decide to implement a contract: automatically or manually - we can't violate SemVer logic just because in some implementation it looks unnatural and still call it SemVer.

Even if we started at 0, once you merge this change into your main branch (possibly via pull request), that's one more commit and it'll be +1 anyway.

That's not actually true, because we change the version only for the official/public change that means merging to a master/main branch (it can be done via the pull request, yes). And we do not change app version when committing to the feature/dev branch, otherwise it's definitely not SemVer. For CI builds of the feature branches can be used build versions like current version + git hash(https://semver.org/#spec-item-10) or yyyymmdd# (default versioning in Azure DevOps): 1.2.3+g9a7eb6c819 and 2022061201 accordingly.

At the moment, it's actually mildly useful that we 'start a 1' because we in fact start at 0, but you only see it before you commit the change. So when you see a value of 0 you know you've changed the version but haven't committed it yet.

Sorry I didn't understand you. Let's consider an example:

1. I did a first initial commit: 1.0.0 // here I will get 1.0.1 so I jumped over a version and got +2 versions according to SemVer
2. I merged a small bugfix: 1.0.1 // here we got an expected behaviour +1 to the previous version 1.0.2
3. I did a backward compatible API change and merged my PR to the main: 1.1.0 // here again I did a one change and commit, but got 1.1.1 +2 versions.

We've got pretty inconsistent behaviour here making +1 or +2 versions.

Also I've read this discussion #102 (comment) (didn't find it before, my bad). And based on what you wrote there you do not want to use x.y.0 because:

1. it's an unlikely scenario - which is a subjective opinion: a lot of libs using x.y.0 versions for the public releases.
2. in your explanation with beta versions you've used them incorrectly. if you want to ship a prerelease of 4.0 after 3.5 you'd want it to be 4.0-beta.1 or 4.0-beta, but you'll be building betas as 4.0.0-beta.15, 4.0.0-beta.20 etc (and not 4.0.15-beta, 4.0.20-beta as you mentioned) And when you are ready to go stable, you'll remove the -beta.* suffix, leaving your version as 4.0.0 as your first stable release. So you can easily get 4.0.0 as a public release version if you follow SemVer.

You versioning schema with 1.0.1 and 4.0.15-beta is perfectly valid as well, but it's not a SemVer. It could be called GitVer, for example. Then I have no questions. But I suppose you've had an intention to support a SemVer versioning, right?

https://semver.org/#spec-item-9

9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.