[GH-ISSUE #67] More context on the rationale for the MUST language related to resetting Patch #6043

New Issue

GiteaMirror · 2026-06-17T04:27:32-05:00

GiteaMirror commented

2026-06-17 04:27:32 -05:00

Originally created by @zimmermatt on GitHub (Feb 15, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/67

The Spec states that patch version must be reset on incrementing the minor version. I'd like to better understand why such a strong restriction on the patch level was chosen.

The context of my question is, in my system, SemVer is essentially followed, but in the case of the patch version the numeric build number from our CI build is used (e.g., 1.0.42, 1.1.46, 2.0.242), since every commit is essentially a patch to the system. The additional advantage is that without effort, essentially at a glance, one can tie the artifact to a build job where rich information about it is stored.

I would like to be able to claim compliance, but not at the expense of having to give up this mechanism for tying an artifact to a build job, especially since it seems to comply with the spirit of SemVer.

So, other than the chance a 2.1.345 might imply to someone there's a 2.1.0 - 2.1.344, what am I missing about the value of the requirement to reset the patch number?

Thanks!

Originally created by @zimmermatt on GitHub (Feb 15, 2013). Original GitHub issue: https://github.com/semver/semver/issues/67 The Spec states that patch version must be reset on incrementing the minor version. I'd like to better understand why such a strong restriction on the patch level was chosen. The context of my question is, in my system, SemVer is essentially followed, but in the case of the patch version the numeric build number from our CI build is used (e.g., 1.0.42, 1.1.46, 2.0.242), since every commit is essentially a patch to the system. The additional advantage is that without effort, essentially at a glance, one can tie the artifact to a build job where rich information about it is stored. I would like to be able to claim compliance, but not at the expense of having to give up this mechanism for tying an artifact to a build job, especially since it seems to comply with the spirit of SemVer. So, other than the chance a 2.1.345 might imply to someone there's a 2.1.0 - 2.1.344, what am I missing about the value of the requirement to reset the patch number? Thanks!

GiteaMirror closed this issue

2026-06-17 04:27:33 -05:00

GiteaMirror commented

2026-06-17 04:27:34 -05:00

@Tieske commented on GitHub (Feb 15, 2013):

You can just replace the second '.' with a '+' and be compliant. So your examples would be 1.0+42, 1.1+46, 2.0+242. Basically; use buildnumbers, not patch numbers.
Then 2.1+345 will no longer imply to someone there's a 2.1.0 - 2.1.344

@Tieske commented on GitHub (Feb 15, 2013): You can just replace the second '.' with a '+' and be compliant. So your examples would be 1.0+42, 1.1+46, 2.0+242. Basically; use buildnumbers, not patch numbers. Then 2.1+345 will no longer imply to someone there's a 2.1.0 - 2.1.344

GiteaMirror commented

2026-06-17 04:27:34 -05:00

@jeffhandley commented on GitHub (Apr 30, 2013):

Can this issue be closed?

@jeffhandley commented on GitHub (Apr 30, 2013): Can this issue be closed?

GiteaMirror commented

2026-06-17 04:27:34 -05:00

@zimmermatt commented on GitHub (Apr 30, 2013):

Sorry, some other priorities came up and I didn't get back to this.

Unfortunately, Tieske's answer would be non-compliant according to item 2 in the spec.

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically by increments of one. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

@zimmermatt commented on GitHub (Apr 30, 2013): Sorry, some other priorities came up and I didn't get back to this. Unfortunately, Tieske's answer would be non-compliant according to item 2 in the spec. 1. A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically by increments of one. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

GiteaMirror commented

2026-06-17 04:27:34 -05:00

@Tieske commented on GitHub (Apr 30, 2013):

That is indeed an omission. If Z is missing in X.Y.Z, then it is assumed to be 0. I think this should be added. Or possibly go into the FAQ.

@Tieske commented on GitHub (Apr 30, 2013): That is indeed an omission. If Z is missing in X.Y.Z, then it is assumed to be 0. I think this should be added. Or possibly go into the FAQ.

GiteaMirror commented

2026-06-17 04:27:35 -05:00

@haacked commented on GitHub (May 6, 2013):

Hmm, I'm not sure anything needs to be changed here. Just update @Tieske's example to include a patch number.

1.0.0+42, 1.1.0+46, 2.0.0+242

The patch should represent an intentional change to the public surface area of the API. It shouldn't be an automated build number. That's exactly what the build metadata is for as @Tieske points out.

I'm going to close this for now. If anyone feels strongly that there's a change needed to reflect this discussion, please send a PR with the proposed wording. Thanks!

@haacked commented on GitHub (May 6, 2013): Hmm, I'm not sure anything needs to be changed here. Just update @Tieske's example to include a patch number. `1.0.0+42`, `1.1.0+46`, `2.0.0+242` The patch should represent an intentional change to the public surface area of the API. It shouldn't be an automated build number. That's _exactly_ what the build metadata is for as @Tieske points out. I'm going to close this for now. If anyone feels strongly that there's a change needed to reflect this discussion, please send a PR with the proposed wording. Thanks!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6043