[GH-ISSUE #929] Semantic version increase by patch even if is hotfix #1448

New Issue

GiteaMirror · 2026-04-16T10:51:40-05:00

GiteaMirror commented

2026-04-16 10:51:40 -05:00

Originally created by @misecca on GitHub (Mar 24, 2023).
Original GitHub issue: https://github.com/semver/semver/issues/929

Actual situation:

main: last tag 0.1.0
create a new branch hotfix/0.1.0
first commit on hotfix/0.1.0 generate a tag 0.1.1-hotfix.1 --> expected 0.1.0-hotfix.1

Originally created by @misecca on GitHub (Mar 24, 2023). Original GitHub issue: https://github.com/semver/semver/issues/929 Actual situation: - main: last tag 0.1.0 - create a new branch hotfix/0.1.0 - first commit on hotfix/0.1.0 generate a tag 0.1.1-hotfix.1 --> expected 0.1.0-hotfix.1

GiteaMirror closed this issue

2026-04-16 10:51:40 -05:00

GiteaMirror commented

2026-04-16 10:51:41 -05:00

@ljharb commented on GitHub (Mar 24, 2023):

There's no such thing as a hotfix in semver. 0.1.0 is fixed with 0.1.1.

@ljharb commented on GitHub (Mar 24, 2023): There's no such thing as a hotfix in semver. 0.1.0 is fixed with 0.1.1.

GiteaMirror commented

2026-04-16 10:51:42 -05:00

@jwdonahue commented on GitHub (Apr 4, 2023):

first commit on hotfix/0.1.0 generate a tag 0.1.1-hotfix.1 --> expected 0.1.0-hotfix.1

Commits should not generate SemVer tags. Revision control systems already have there own way of versioning what's in them. Adding version information in a commit is faulty design and will not scale. Build/package/release systems generate SemVer versionable artifacts, if those artifacts are universally unique per version string (hard to do at scale, but do-able). Whether such systems label the repo hash with the generated version of the artifact(s) created from it, is a matter of taste, but there can be multiple unique artifacts for any given repo content hash, so you're concept of version labels on commits is broken.

@jwdonahue commented on GitHub (Apr 4, 2023): > first commit on hotfix/0.1.0 generate a tag 0.1.1-hotfix.1 --> expected 0.1.0-hotfix.1 Commits should not generate SemVer tags. Revision control systems already have there own way of versioning what's in them. Adding version information in a commit is faulty design and will not scale. Build/package/release systems generate SemVer versionable artifacts, if those artifacts are universally unique per version string (hard to do at scale, but do-able). Whether such systems label the repo hash with the generated version of the artifact(s) created from it, is a matter of taste, but there can be multiple unique artifacts for any given repo content hash, so you're concept of version labels on commits is broken.

GiteaMirror commented

2026-04-16 10:51:42 -05:00

@steveklabnik commented on GitHub (Apr 6, 2023):

There's no such thing as a hotfix in semver. 0.1.0 is fixed with 0.1.1.

This is correct, yes.

@steveklabnik commented on GitHub (Apr 6, 2023): > There's no such thing as a hotfix in semver. 0.1.0 is fixed with 0.1.1. This is correct, yes.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1448