[GH-ISSUE #400] Missing good reasoning for Minor vs Patch logic #4542

New Issue

GiteaMirror · 2026-06-13T12:44:55-05:00

GiteaMirror commented

2026-06-13 12:44:55 -05:00

Originally created by @Vaccano on GitHub (Oct 12, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/400

On the home page there is great logic for when a Major vs Minor number change is needed. I am fully on board with that.

But I would like to know the "why" behind the logic is for the third number (aka "Patch"). The page says it can only be for bug fixes. (Note that I personally don't have an issue with this, but I have a company who wants to use Minor for a group a features, and Patch for all the releases that it takes to get to that group of features.

I want to follow best practices, and SemVer seems to be one of those. But best practices usually have a solid reason behind them. And I need to know that so I can try to convince those in control of the process.

Originally created by @Vaccano on GitHub (Oct 12, 2017). Original GitHub issue: https://github.com/semver/semver/issues/400 On the [home page](http://semver.org/spec/v2.0.0.html) there is great logic for when a Major vs Minor number change is needed. I am fully on board with that. But I would like to know the "why" behind the logic is for the third number (aka "Patch"). The page says it can only be for bug fixes. (Note that I personally don't have an issue with this, but I have a company who wants to use Minor for a group a features, and Patch for all the releases that it takes to get to that group of features. I want to follow best practices, and SemVer seems to be one of those. But best practices usually have a solid reason behind them. And I need to know that so I can try to convince those in control of the process.

GiteaMirror closed this issue

2026-06-13 12:44:56 -05:00

GiteaMirror commented

2026-06-13 12:44:57 -05:00

@haacked commented on GitHub (Oct 16, 2017):

Semver is primarily about communicating risk to consumers of a library/package. When you increment "patch", you're communicating that the risk is very small for upgrading to this patch. In fact, it tends to communicate there's risk in not upgrading (in cases where a security bug is patched.)

A minor update might also be safe to take, but there's more risk because new features were added, albeit in a non-breaking manner. But a minor update might have a wide range of changes. A patch update should only contain very targeted bug fixes.

@haacked commented on GitHub (Oct 16, 2017): Semver is primarily about communicating risk to consumers of a library/package. When you increment "patch", you're communicating that the risk is very small for upgrading to this patch. In fact, it tends to communicate there's risk in not upgrading (in cases where a security bug is patched.) A minor update might _also_ be safe to take, but there's more risk because new features were added, albeit in a non-breaking manner. But a minor update might have a wide range of changes. A patch update should only contain very targeted bug fixes.

GiteaMirror commented

2026-06-13 12:44:58 -05:00

@KyNorthstar commented on GitHub (Sep 21, 2019):

Major: Forces you to change the way you do things
Minor: Adds new capabilities but you can keep doing things the same way
Patch: Behind-the-scenes change

@KyNorthstar commented on GitHub (Sep 21, 2019): **Major:** Forces you to change the way you do things **Minor:** Adds new capabilities but you can keep doing things the same way **Patch:** Behind-the-scenes change

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4542