Skip to content

Incorrect statement regarding version increment with regard to SemVer. #2132

@jwdonahue

Description

@jwdonahue

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions