[GH-ISSUE #928] Suggestion to Expand SemVer Specifications to Include Publicity Field #2314

New Issue

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

GiteaMirror commented

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

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

Firstly, I would like to commend you on the excellent work you have done with the Semantic Versioning (SemVer) system. It provides a clear and concise way to represent version numbers and helps developers to communicate changes in a consistent manner.

However, I have noticed that there is currently no provision for a "publicity" field in SemVer. While the major version number is typically used to indicate major changes or new features, it is not always clear to the end-user what this means in terms of publicity or marketing.

I propose that we consider expanding the SemVer specifications to include a "publicity" field, which would allow developers to explicitly indicate the level of publicity associated with a particular release. This could be represented as a fourth field in the version number, following the existing major, minor, and patch fields.

For example, a version number could be represented as "v1.0.0.1" to indicate first publicity version, while "v2.0.0.0" could represent a new version.

I believe that this addition would provide a more comprehensive and nuanced way to communicate changes to end-users, and would be a valuable addition to the SemVer system.

Originally created by @ayoubelmhamdi on GitHub (Mar 24, 2023). Original GitHub issue: https://github.com/semver/semver/issues/928 Firstly, I would like to commend you on the excellent work you have done with the Semantic Versioning (SemVer) system. It provides a clear and concise way to represent version numbers and helps developers to communicate changes in a consistent manner. However, I have noticed that there is currently no provision for a "publicity" field in SemVer. While the major version number is typically used to indicate `major changes` or `new features`, it is not always clear to the end-user what this means in terms of publicity or marketing. I propose that we consider expanding the SemVer specifications to include a "publicity" field, which would allow developers to explicitly indicate the level of publicity associated with a particular release. This could be represented as a fourth field in the version number, following the existing major, minor, and patch fields. For example, a version number could be represented as "v1.0.0.1" to indicate first publicity version, while "v2.0.0.0" could represent a new version. I believe that this addition would provide a more comprehensive and nuanced way to communicate changes to end-users, and would be a valuable addition to the SemVer system.

GiteaMirror closed this issue

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

GiteaMirror commented

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

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

some benefit:

Faster release cycles: The addition of a "publicity" field would allow developers to release new versions more frequently without having to change the major version number unnecessarily. This would result in faster release cycles and more timely updates.
Reduced confusion and errors: By not having to change the major version number for every new feature or change, developers can avoid confusion and errors that can occur when dealing with multiple major version numbers for the same product.
Improved version control: The addition of a "publicity" field would allow for more granular version control and tracking of changes, making it easier to manage and maintain code repositories.
Streamlined development processes: By providing a more specific way to indicate the level of publicity associated with a release, developers can streamline their development processes and avoid unnecessary delays or roadblocks.

@ayoubelmhamdi commented on GitHub (Mar 24, 2023): some benefit: - Faster release cycles: The addition of a "publicity" field would allow developers to release new versions more frequently without having to change the major version number unnecessarily. This would result in faster release cycles and more timely updates. - Reduced confusion and errors: By not having to change the major version number for every new feature or change, developers can avoid confusion and errors that can occur when dealing with multiple major version numbers for the same product. - Improved version control: The addition of a "publicity" field would allow for more granular version control and tracking of changes, making it easier to manage and maintain code repositories. - Streamlined development processes: By providing a more specific way to indicate the level of publicity associated with a release, developers can streamline their development processes and avoid unnecessary delays or roadblocks.

GiteaMirror commented

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

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

Duplicate of #891. Duplicate of #340. Duplicate of #213.

You should only be changing the major version number with breaking changes, not just adding new features or fixing bugs, and the intended effect here is to both discourage breaking changes and to clearly denote them. Adding a fourth number would add a lot of confusion here.

@ljharb commented on GitHub (Mar 24, 2023): Duplicate of #891. Duplicate of #340. Duplicate of #213. You should only be changing the major version number with *breaking* changes, not just adding new features or fixing bugs, and the *intended* effect here is to both discourage breaking changes and to clearly denote them. Adding a fourth number would add a *lot* of confusion here.

GiteaMirror commented

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

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

You should only be changing the major version number with breaking changes, not just adding new features or fixing bugs...

I definitely agree, with an emphasis on SHOULD.

... and the intended effect here is to both discourage breaking changes and ...

I have never seen any comments from the original author or contributors to that effect. The spec is in fact agnostic on whether breaking changes are are good or bad. It merely states how to convey a certain level of risk to the consumer in any given release.

If I were to design a version scheme that discourages breaking changes, I would eliminate the major version field and state clearly that developers should rename the product and start fresh at 1.0 or 0.0. I would probably also add a quality field such that Q.F.P where Q is a number from 0..9 indicating some predefined levels of testing/inspection and the F.P has the same rules as SemVer. For that matter, A.Q.F.P where the A fields indicates some well defined levels of professional auditing, etc. But I would not be trying to change SemVer, I would add my spec to the set of all semantic versioning schemes.

LOL, if a Q of zero meant something like "prelease/prototype with potentially no or undefined level of testing", then we'd have an initial starting point that is indistinguishable from SemVers 0.y.z form.

@jwdonahue commented on GitHub (Apr 3, 2023): > You should only be changing the major version number with breaking changes, not just adding new features or fixing bugs... I definitely agree, with an emphasis on SHOULD. > ... and the intended effect here is to both discourage breaking changes and ... I have never seen any comments from the original author or contributors to that effect. The spec is in fact agnostic on whether breaking changes are are good or bad. It merely states how to convey a certain level of risk to the consumer in any given release. If I were to design a version scheme that discourages breaking changes, I would eliminate the major version field and state clearly that developers should rename the product and start fresh at 1.0 or 0.0. I would probably also add a quality field such that Q.F.P where Q is a number from 0..9 indicating some predefined levels of testing/inspection and the F.P has the same rules as SemVer. For that matter, A.Q.F.P where the A fields indicates some well defined levels of professional auditing, etc. But I would not be trying to change SemVer, I would add my spec to the set of all semantic versioning schemes. ---- LOL, if a Q of zero meant something like "prelease/prototype with potentially no or undefined level of testing", then we'd have an initial starting point that is indistinguishable from SemVers 0.y.z form.

GiteaMirror commented

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

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

@ayoubelmhamdi

If SemVer were expanded to include a field for every semantic ever proposed here, it would have a potentially infinite number of fields and interpretations. Version strings that employ other semantics than SemVer, just aren't SemVer. You are free to fork and modify the spec for whatever flavor(s) of versioning you like. If you are really interested in this sort of thing take a look at Version Schema and Version Meta.

@jwdonahue commented on GitHub (Apr 3, 2023): @ayoubelmhamdi If SemVer were expanded to include a field for every semantic ever proposed here, it would have a potentially infinite number of fields and interpretations. Version strings that employ other semantics than SemVer, just aren't SemVer. You are free to fork and modify the spec for whatever flavor(s) of versioning you like. If you are really interested in this sort of thing take a look at [Version Schema](https://www.versionschema.org/) and [Version Meta](https://www.versionmeta.org/).

GiteaMirror commented

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

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

Yes, this is unlikely to ever happen.

@steveklabnik commented on GitHub (Apr 6, 2023): Yes, this is unlikely to ever happen.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2314