github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-07-11 05:12:48 -05:00
Code Issues 1.0k Packages Projects Releases 4 Wiki Activity

Semantic version increase by patch even if is hotfix #582

New Issue
Closed
opened 2026-02-17 12:13:56 -06:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-02-17 12:13:56 -06:00
Owner
Copy Link

Originally created by @misecca on GitHub (Mar 24, 2023).

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). 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 commented 2026-02-17 12:13:58 -06:00
Author
Owner
Copy Link

@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-02-17 12:13:58 -06:00
Author
Owner
Copy Link

@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-02-17 12:13:59 -06:00
Author
Owner
Copy Link

@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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
consensus seeking
duplicate
extend
layout
pull-request
Mirrored from GitHub Pull Request
 question
RFC
spelling/grammar
staled
update
waiting for PR
won't fix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#582
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?