[GH-ISSUE #778] Make it clear semver has matured past a "proposal" #7488

New Issue

GiteaMirror · 2026-06-20T17:34:20-05:00

GiteaMirror commented

2026-06-20 17:34:20 -05:00

Originally created by @aaaidan on GitHub (Dec 2, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/778

The spec uses words like "we propose" a fair bit, which makes it sound as though it is still a speculative RFC. It seems clear to me that semver is widely accepted and widely used in the software industry (and beyond!)

I propose that we re-word some parts of the spec to be less circumspect, and more directive.

Originally created by @aaaidan on GitHub (Dec 2, 2021). Original GitHub issue: https://github.com/semver/semver/issues/778 The spec uses words like "we propose" a fair bit, which makes it sound as though it is still a speculative RFC. It seems clear to me that semver is widely accepted and widely used in the software industry (and beyond!) I propose that we re-word some parts of the spec to be less circumspect, and more directive.

GiteaMirror commented

2026-06-20 17:34:21 -05:00

@jwdonahue commented on GitHub (Dec 4, 2021):

It is still a speculative RFC. There's no one governing board out there that gets to decide what the standard is wrt versioning. There isn't even a consensus around best practices. SemVer is one among many that have proven useful. As for "widely adopted" I would agree, to the extent that there are more than a handful of tools that support it properly. But keep in mind that:

Many of the most popular of those tools, also support other formats and semantics/workflows as well.
Many, if not most of the SemVer adopters, do not agree with each other how it should be correctly applied.
Some of the most widely distributed software, as in billions of customers, do not use anything at all like SemVer.

I would also point out there are some actual software industry governing boards that have their own well defined standards.

@jwdonahue commented on GitHub (Dec 4, 2021): It is still a speculative RFC. There's no one governing board out there that gets to decide what the standard is wrt versioning. There isn't even a consensus around best practices. SemVer is one among many that have proven useful. As for "widely adopted" I would agree, to the extent that there are more than a handful of tools that support it properly. But keep in mind that: - Many of the most popular of those tools, also support other formats and semantics/workflows as well. - Many, if not most of the SemVer adopters, do not agree with each other how it should be correctly applied. - Some of the most widely distributed software, as in billions of customers, do not use anything at all like SemVer. I would also point out there are some actual software industry governing boards that have their own well defined standards.

GiteaMirror commented

2026-06-20 17:34:21 -05:00

@aaaidan commented on GitHub (Dec 4, 2021):

Thanks @jwdonahue, that all makes a lot of sense. Semvar is just one of many possible strategies and there can be no One True Way for versioning. It’s also not “finished” - and may never be!

For those considering semvar as a versioning strategy (or are simply learning about it), some of the spec wording implies it is still at a very early, and very tentative proposal stage. I think it suggests no real-world agreement or adoption, which is no longer true.

I suggest updating the spec’s tone to match semvar’s current maturity. I think this can be done in a way that doesn’t conflict with the points you’ve raised.

@aaaidan commented on GitHub (Dec 4, 2021): Thanks @jwdonahue, that all makes a lot of sense. Semvar is just one of many possible strategies and there can be no One True Way for versioning. It’s also not “finished” - and may never be! For those considering semvar as a versioning strategy (or are simply learning about it), some of the spec wording implies it is still at a very early, and very tentative proposal stage. I think it suggests no real-world agreement or adoption, which is no longer true. I suggest updating the spec’s tone to match semvar’s current maturity. I think this can be done in a way that doesn’t conflict with the points you’ve raised.

GiteaMirror commented

2026-06-20 17:34:21 -05:00

@jwdonahue commented on GitHub (Dec 4, 2021):

You are always welcome to present a PR/RFC. Just keep in mind that the tone of the current document has contributed to its extensive adoption. It's a distillation of common practice in versioning. It doesn't over-constrain the problem, but seems to get it just about right. It is also the inspiration/basis for more formal specifications.

It’s also not “finished” - and may never be!

If you ask the current maintainers, it's essentially done. They all own packaging tools for a variety of development ecosystems. They all have vested interests in maintaining the status-quo. If you are careful about your proposed new wording, they might accept it. You have to be careful to avoid any prescriptive statements that any one of their tools, doesn't currently abide by. They wish to document only that which is common to all of them. So tonal changes might be accepted. They, me and many others, wish to ensure that we always have the freedom to innovate.

The document was originally written by one person, probably to garner consensus among early developers (employees) of GitHub, as well as their customers. Hence, the "I propose" style language in the original document, apparently updated to "we propose" without actually adhering to the original proposal and bumping the version number.

And now that I got this far into this response, I see you do have a PR, so I will go look at that now...

@jwdonahue commented on GitHub (Dec 4, 2021): You are always welcome to present a PR/RFC. Just keep in mind that the tone of the current document has contributed to its extensive adoption. It's a distillation of common practice in versioning. It doesn't over-constrain the problem, but seems to get it just about right. It is also the inspiration/basis for more formal specifications. > It’s also not “finished” - and may never be! If you ask the current maintainers, it's essentially done. They all own packaging tools for a variety of development ecosystems. They all have vested interests in maintaining the status-quo. If you are careful about your proposed new wording, they might accept it. You have to be careful to avoid any prescriptive statements that any one of their tools, doesn't currently abide by. They wish to document only that which is common to all of them. So tonal changes might be accepted. They, me and many others, wish to ensure that we always have the freedom to innovate. The document was originally written by one person, probably to garner consensus among early developers (employees) of GitHub, as well as their customers. Hence, the "I propose" style language in the original document, apparently updated to "we propose" without actually adhering to the original proposal and bumping the version number. And now that I got this far into this response, I see you do have a PR, so I will go look at that now...

GiteaMirror commented

2026-06-20 17:34:22 -05:00

@gsmethells commented on GitHub (Nov 25, 2025):

What standard (RFC reference welcome) is there for versioning beyond semver.org?

@gsmethells commented on GitHub (Nov 25, 2025): What standard (RFC reference welcome) is there for versioning beyond semver.org?

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#7488