-
Notifications
You must be signed in to change notification settings - Fork 662
Description
The doc on Version Incrementing, first paragraph under Approach reads:
Bumping one of the version components by more than 1 in a single release means you will have gaps in your version number, which defeats the purpose of SemVer.
This is not a true a statement. Nothing in the SemVer spec says that version numbers should be linear or monotonic. Any particular repository of versioned packages may in fact have gaps due to deletions, or due to skipped or dropped versions that were never published. Skipping N versions per release is a common enough practice that all tooling should expect or support it.
The SemVer spec is agnostic regarding workflows. The spec says exactly what it must say, to define/convey the meaning/intent of semantic versioning, and nothing more. The following version history is perfectly acceptable:
0.1.0
1.0.0
1.2.0
1.2.5
1.2.1
While you might think that last one was pointless, the available information, beyond the release history found in the package feed, cannot convey sufficient information to make that determination, nor are pointless releases banned by the spec.
If GitVersion is limited to increment by one, it is an arbitrary feature of your tool that has nothing to do with the purpose of SemVer.