[GH-ISSUE #523] Introduce a named concept for a version without pre-release label and without build metadata #2119

New Issue

GiteaMirror · 2026-04-20T10:04:16-05:00

GiteaMirror commented

2026-04-20 10:04:16 -05:00

Originally created by @basbossink on GitHub (Jul 8, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/523

Spec-item2 states:

A normal version number MUST take the form X.Y.Z .....

The word normal is a bit odd here. I believe that a proper name for the part of the semver containing only Major.Minor.Patch could really help make some other parts of the specification easier to read.

Some suggestions:

bare
primary
simple
unadorned

Using for instance the word unadordened a reformulation of the summary could read:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the unadorned MAJOR.MINOR.PATCH format.

Using for instance the word unadordened a reformulation of spec item 2 could read:

The unadorned version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

Apparently the BNF uses the term version core but the text of the specification does not use a name for the same concept.

Originally created by @basbossink on GitHub (Jul 8, 2019). Original GitHub issue: https://github.com/semver/semver/issues/523 [Spec-item2](https://semver.org/#spec-item-2) states: > A normal version number MUST take the form X.Y.Z ..... The word _normal_ is a bit odd here. I believe that a proper name for the part of the semver containing only Major.Minor.Patch could really help make some other parts of the specification easier to read. Some suggestions: * bare * primary * simple * unadorned Using for instance the word _unadordened_ a reformulation of the summary could read: Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the unadorned MAJOR.MINOR.PATCH format. Using for instance the word _unadordened_ a reformulation of spec item 2 could read: > The unadorned version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0. Apparently the [BNF](https://github.com/semver/semver/blob/master/semver.md#backusnaur-form-grammar-for-valid-semver-versions) uses the _term_ `version core` but the text of the specification does not use a name for the same concept.

GiteaMirror closed this issue

2026-04-20 10:04:17 -05:00

GiteaMirror commented

2026-04-20 10:04:18 -05:00

@runeimp commented on GitHub (Jul 8, 2019):

I agree with the sentiment. Though I think core, as the core version designation, and as used in the BNF is probably fine.

@runeimp commented on GitHub (Jul 8, 2019): I agree with the sentiment. Though I think _core_, as the core version designation, and as used in the [BNF](https://github.com/semver/semver/blob/master/semver.md#backusnaur-form-grammar-for-valid-semver-versions) is probably fine.

GiteaMirror commented

2026-04-20 10:04:19 -05:00

@jwdonahue commented on GitHub (Aug 10, 2019):

Most of us simply refer to it as the version triple. I think "version core" is a misnomer and wish I had spotted it earlier. I agree the spec could use a tune-up here, but I don't like "unadorned version number", because it is not always unadorned, nor does the spec prohibit adornment, and it's not a version number, it's a tuple or more precisely a triplet of dot separated numeric fields.

@jwdonahue commented on GitHub (Aug 10, 2019): Most of us simply refer to it as the version triple. I think "version core" is a misnomer and wish I had spotted it earlier. I agree the spec could use a tune-up here, but I don't like "unadorned version number", because it is not always unadorned, nor does the spec prohibit adornment, and it's not a version number, it's a [tuple](https://www.dictionary.com/browse/tuple) or more precisely a triplet of dot separated numeric fields.

GiteaMirror commented

2026-04-20 10:04:19 -05:00

@jwdonahue commented on GitHub (Aug 27, 2019):

@basbossink, unless you intend to issue a PR or you have further questions. Please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Aug 27, 2019): @basbossink, unless you intend to issue a PR or you have further questions. Please close this issue at your earliest possible convenience.

GiteaMirror commented

2026-04-20 10:04:20 -05:00

@basbossink commented on GitHub (Sep 2, 2019):

Given the above discussion I don't think there is a clear winner on how change the spec resolving the issue raised. I think using the term "version triple" especially in spec item 2 would result in a weird form of duplication. So I will close this issue, if anyone can come up with a better formulation, a new issue can be created.

@basbossink commented on GitHub (Sep 2, 2019): Given the above discussion I don't think there is a _clear winner_ on how change the spec resolving the issue raised. I think using the term "version triple" especially in spec item 2 would result in a weird form of duplication. So I will close this issue, if anyone can come up with a better formulation, a new issue can be created.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2119