[GH-ISSUE #799] Is semver versioned with semver? #4770

New Issue

GiteaMirror · 2026-06-13T13:09:01-05:00

GiteaMirror commented

2026-06-13 13:09:01 -05:00

Originally created by @jcornaz on GitHub (Jan 28, 2022).
Original GitHub issue: https://github.com/semver/semver/issues/799

Hi,

I see that https://semver.org is versioned and we currently sit at version 2.0.0

Intuitively I'd expect it to use semantic versioning to version itself. But it looks like it doesn't?

I noticed the latest version is 2.0.0, published in june 2013. But the readme of this repository states:

Changes to the document are published to the website by a GitHub Actions workflow which runs once each day.

Does that mean it is not versionned at all?

And if it is versioned with semver, how would the first point of the spec apply?

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive.

Does that mean that because it is not a software, it doesn't declare a public API, and therefore anything can change at anytime?

Originally created by @jcornaz on GitHub (Jan 28, 2022). Original GitHub issue: https://github.com/semver/semver/issues/799 Hi, I see that https://semver.org is versioned and we currently sit at version 2.0.0 Intuitively I'd expect it to use semantic versioning to version itself. But it looks like it doesn't? I noticed the latest version is 2.0.0, published in june 2013. But the readme of this repository states: > Changes to the document are published to the website by a GitHub Actions workflow which runs once each day. Does that mean it is not versionned at all? And if it is versioned with semver, how would the first point of the spec apply? > Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive. Does that mean that because it is not a software, it doesn't declare a public API, and therefore anything can change at anytime?

GiteaMirror commented

2026-06-13 13:09:02 -05:00

@Saklad5 commented on GitHub (Feb 11, 2022):

I interpret that requirement as mandating explicit declaration of a public interface. That is, you are required to specify the scope of the version you provide.

If the version is attached to code, that means specifying a public API. If the version is attached to other things (such as a compiled application binary or a specification), it may mean something else.

@Saklad5 commented on GitHub (Feb 11, 2022): I interpret that requirement as mandating _explicit_ declaration of a public interface. That is, you are required to specify the scope of the version you provide. If the version is attached to code, that means specifying a public API. If the version is attached to other things (such as a compiled application binary or a specification), it may mean something else.

GiteaMirror commented

2026-06-13 13:09:03 -05:00

@jcornaz commented on GitHub (Feb 11, 2022):

If the version is attached to other things (such as a compiled application binary or a specification), it may mean something else.

That sounds quite problematic. Especially for the versioning of semver itself. Assuming it is indeed versioned with semver because we still don't know...

It would be nice to know what is the scope for the semver version. What kind of change would make it bump to: 2.0.1, 2.1.0, or 3.0.0?

@jcornaz commented on GitHub (Feb 11, 2022): > If the version is attached to other things (such as a compiled application binary or a specification), it may mean something else. That sounds quite problematic. Especially for the versioning of semver itself. Assuming it is indeed versioned with semver because we still don't know... It would be nice to know what is the scope for the semver version. What kind of change would make it bump to: 2.0.1, 2.1.0, or 3.0.0?

GiteaMirror commented

2026-06-13 13:09:03 -05:00

@Saklad5 commented on GitHub (Feb 11, 2022):

It would be nice to know what is the scope for the semver version. What kind of change would make it bump to: 2.0.1, 2.1.0, or 3.0.0?

Simple: it’s based on how conformance is affected by the update.

A patch release means everything conforming to the previous version conforms to the new version. An obvious example would be fixing typos or rewording something without changing its meaning.
A minor release means everything conforming to the new version conforms to the previous version. This could mean adding additional rules, such as requiring 0.y.0 to be a minor release rather than a major one.
A major release means something conforming to the new version may not conform to the previous version. This could mean removing rules, such as allowing any Unicode characters to be used in an identifier.

@Saklad5 commented on GitHub (Feb 11, 2022): > It would be nice to know what is the scope for the semver version. What kind of change would make it bump to: 2.0.1, 2.1.0, or 3.0.0? Simple: it’s based on how conformance is affected by the update. - A patch release means everything conforming to the previous version conforms to the new version. An obvious example would be fixing typos or rewording something without changing its meaning. - A minor release means everything conforming to the new version conforms to the previous version. This could mean adding additional rules, such as requiring 0.y.0 to be a minor release rather than a major one. - A major release means something conforming to the new version may not conform to the previous version. This could mean removing rules, such as allowing any Unicode characters to be used in an identifier.

GiteaMirror commented

2026-06-13 13:09:03 -05:00

@jcornaz commented on GitHub (Feb 11, 2022):

I don't think it is that simple, or at least not that obvious. And even it if was, it should at least be documented. I am still waiting for a statement from the maintainers of this repository.

A patch release means everything conforming to the previous version conforms to the new version. An obvious example would be fixing typos or rewording something without changing its meaning.

It is not what is happening. Here is what has changed since version 2.0.0: https://github.com/semver/semver/compare/v2.0.0...master

Yet the version number hasn't changed at all. Not even to 2.0.1

A minor release means everything conforming to the new version conforms to the previous version. This could mean adding additional rules, such as requiring 0.y.0 to be a minor release rather than a major one.

I would consider adding additional rules to be a breaking change. Because library authors that claimed to follow semver would now have to adjust their knowledge and process to conform to the new rules. And past releases may no longer be semver compliant, even if they were compliant when released.

@jcornaz commented on GitHub (Feb 11, 2022): I don't think it is that simple, or at least not that obvious. And even it if was, it should at least be documented. I am still waiting for a statement from the maintainers of this repository. > A patch release means everything conforming to the previous version conforms to the new version. An obvious example would be fixing typos or rewording something without changing its meaning. It is not what is happening. Here is what has changed since version 2.0.0: https://github.com/semver/semver/compare/v2.0.0...master Yet the version number hasn't changed at all. Not even to 2.0.1 > A minor release means everything conforming to the new version conforms to the previous version. This could mean adding additional rules, such as requiring 0.y.0 to be a minor release rather than a major one. I would consider adding additional rules to be a breaking change. Because library authors that claimed to follow semver would now have to adjust their knowledge and process to conform to the new rules. And past releases may no longer be semver compliant, even if they were compliant when released.

GiteaMirror commented

2026-06-13 13:09:04 -05:00

@Saklad5 commented on GitHub (Feb 11, 2022):

True. I feel they should be incrementing the patch version whenever they change the actual spec.

I would consider adding additional rules to be a breaking change. Because library authors that claimed to follow semver would now have to adjust their knowledge and process to conform to the new rules.

I’m looking at it from the perspective of expectations: if you expect all of the rules of 2.0.0, you could use something following a hypothetical 2.1.0. If you expect all of the rules of 2.1.0, however, you may not be able to work with something that only follows 2.0.0.

And past releases may no longer be semver compliant, even if they were compliant when released.

They would still be compliant with the version of SemVer that they specified: versions are immutable, in theory. If they didn’t specify a version, they’ve screwed up.

@Saklad5 commented on GitHub (Feb 11, 2022): True. I feel they should be incrementing the patch version whenever they change the actual spec. > I would consider adding additional rules to be a breaking change. Because library authors that claimed to follow semver would now have to adjust their knowledge and process to conform to the new rules. I’m looking at it from the perspective of expectations: if you expect all of the rules of 2.0.0, you could use something following a hypothetical 2.1.0. If you expect all of the rules of 2.1.0, however, you may not be able to work with something that only follows 2.0.0. > And past releases may no longer be semver compliant, even if they were compliant when released. They would still be compliant with the version of SemVer that they specified: versions are immutable, in theory. If they didn’t specify a version, they’ve screwed up.

GiteaMirror commented

2026-06-13 13:09:05 -05:00

@jcornaz commented on GitHub (Feb 11, 2022):

I’m looking at it from the perspective of expectations

Ah well, of course, it depends on the perspective. And that's precisely the problem. But because it is not documented, then we can only guess.

Needless to say that if your definition is actually what is applied, then as a library author I do not want to follow semantic versioning. I don't want to find myself that with past releases that are suddenly not semver compliant, just because the specification has changed after my releases.

@jcornaz commented on GitHub (Feb 11, 2022): > I’m looking at it from the perspective of expectations Ah well, of course, it depends on the perspective. And that's precisely the problem. But because it is not documented, then we can only guess. Needless to say that if your definition is actually what is applied, then as a library author I do *not* want to follow semantic versioning. I don't want to find myself that with past releases that are suddenly not semver compliant, just because the specification has changed after my releases.

GiteaMirror commented

2026-06-13 13:09:05 -05:00

@Saklad5 commented on GitHub (Feb 11, 2022):

I don't want to find myself that my past releases are suddenly not semver compliant, just because the specification has changed after my releases.

That can’t happen. If you comply with Semantic Versioning 2.0.0, you will always comply with Semantic Versioning 2.0.0.

@Saklad5 commented on GitHub (Feb 11, 2022): > I don't want to find myself that my past releases are suddenly not semver compliant, just because the specification has changed after my releases. That can’t happen. If you comply with Semantic Versioning 2.0.0, you will _always_ comply with Semantic Versioning 2.0.0.

GiteaMirror commented

2026-06-13 13:09:06 -05:00

@jcornaz commented on GitHub (Feb 11, 2022):

They would still be compliant with the version of SemVer that they specified: versions are immutable, in theory. If they didn’t specify a version, they’ve screwed up.

No, they wouldn't. If I say I follow semver 2.0.0, then it should work with semver 2.1.0, but it doesn't because I don't follow the new rules. If you want a code analogy, it is like adding a new member to an interface. That is a breaking change for every user that implement the interface because they must implement the new member.

@jcornaz commented on GitHub (Feb 11, 2022): > They would still be compliant with the version of SemVer that they specified: versions are immutable, in theory. If they didn’t specify a version, they’ve screwed up. No, they wouldn't. If I say I follow semver 2.0.0, then it should work with semver 2.1.0, but it doesn't because I don't follow the new rules. If you want a code analogy, it is like adding a new member to an interface. That is a breaking change for every user that implement the interface because they *must* implement the new member.

GiteaMirror commented

2026-06-13 13:09:06 -05:00

@Saklad5 commented on GitHub (Feb 11, 2022):

That is not how specifications work. In specifications, rules are tantamount to features: you are required to do a or implement b. This dates back far beyond SemVer, even.

As an example, if something claimed to support HTTP/1.0, you would not expect it to have all the features of HTTP/1.1. If something claimed to support HTTP/2, you could not (from the version alone) assume HTTP/1.1 clients or servers would work with it.

@Saklad5 commented on GitHub (Feb 11, 2022): That is not how specifications work. In specifications, rules are tantamount to features: you are required to do _a_ or implement _b_. This dates back far beyond SemVer, even. As an example, if something claimed to support HTTP/1.0, you would not expect it to have all the features of HTTP/1.1. If something claimed to support HTTP/2, you could not (from the version alone) assume HTTP/1.1 clients or servers would work with it.

GiteaMirror commented

2026-06-13 13:09:07 -05:00

@jcornaz commented on GitHub (Feb 11, 2022):

I'm glad to know your opinion @Saklad5. But, I am sad that @semver/maintainers still don't want to state how semver is actually versioned.

@jcornaz commented on GitHub (Feb 11, 2022): I'm glad to know your opinion @Saklad5. But, I am sad that @semver/maintainers still don't want to state how semver is actually versioned.

GiteaMirror commented

2026-06-13 13:09:07 -05:00

@jcornaz commented on GitHub (Feb 11, 2022):

As an example, if something claimed to support HTTP/1.0, you would not expect it to have all the features of HTTP/1.1. If something claimed to support HTTP/2, you could not (from the version alone) assume HTTP/1.1 clients or servers would work with it.

I think this example is irrelevant because HTTP doesn't follow semantic versioning. And even if it would, it depends on what they defined as the public API. If they state the public API is from the point of view of the consumer only, then it's fine. But the API surface still has to be clearly defined.

In the case of semver, we don't even know if they follow semver!

That is not how specifications work. In specifications, rules are tantamount to features: you are required to do a or implement b.
This dates back far beyond SemVer, even.

If it predates semver, that statement is void. We are talking about semver here.

@jcornaz commented on GitHub (Feb 11, 2022): > As an example, if something claimed to support HTTP/1.0, you would not expect it to have all the features of HTTP/1.1. If something claimed to support HTTP/2, you could not (from the version alone) assume HTTP/1.1 clients or servers would work with it. I think this example is irrelevant because HTTP doesn't follow semantic versioning. And even if it would, it depends on what they defined as the public API. If they state the public API is from the point of view of the consumer only, then it's fine. But the API surface still has to be clearly defined. In the case of semver, we don't even know if they follow semver! > That is not how specifications work. In specifications, rules are tantamount to features: you are required to do a or implement b. > This dates back far beyond SemVer, even. If it predates semver, that statement is void. We are talking about semver here.

GiteaMirror commented

2026-06-13 13:09:08 -05:00

@nezmaka commented on GitHub (Feb 18, 2022):

It would be nice to know what is the scope for the semver version. What kind of change would make it bump to: 2.0.1, 2.1.0, or 3.0.0?

Simple: it’s based on how conformance is affected by the update.

* A patch release means everything conforming to the previous version conforms to the new version. An obvious example would be fixing typos or rewording something without changing its meaning.

* A minor release means everything conforming to the new version conforms to the previous version. This could mean adding additional rules, such as requiring 0.y.0 to be a minor release rather than a major one.

* A major release means something conforming to the new version may not conform to the previous version. This could mean removing rules, such as allowing any Unicode characters to be used in an identifier.

Regardless of the fact that the maintainers of semver should provide the answer, I think you put it quite nicely. Nonetheless, I think you got minor and major mixed up –– which is what, I think, @jcornaz has been addressing.
As I see it, the "feature - rule" analogy does not hold here, and, regardless, semvar specifications speak of a public API, not of "features".
The addition of rules makes a specification more stringent; their removal makes it laxer. If you remove rules, what has hitherto conformed, conforms still. That's a minor change. If you add rules, what has hitherto conformed, might not conform with the new rules. That's a major change.

So I'd have modified your interpretation thus:

A patch release means everything conforming to the previous version conforms to the new version. An obvious example would be fixing typos or rewording something without changing its meaning.
A minor release means everything conforming to the new version conforms to the previous version. This could mean removing rules (i.e. less MUSTs and MUST NOTs) or making them less stringent (MUST becomes a MAY). That would be, for example, allowing any Unicode characters to be used in an identifier (and not only ASCII alphanumerics and hyphens).
A major release means something conforming to the new version may not conform to the previous version. This could mean adding rules, such as a requirement that major patch identifiers must be even integers and that minor patch identifiers should be odd integers.

@nezmaka commented on GitHub (Feb 18, 2022): > > It would be nice to know what is the scope for the semver version. What kind of change would make it bump to: 2.0.1, 2.1.0, or 3.0.0? > > Simple: it’s based on how conformance is affected by the update. > > * A patch release means everything conforming to the previous version conforms to the new version. An obvious example would be fixing typos or rewording something without changing its meaning. > > * A minor release means everything conforming to the new version conforms to the previous version. This could mean adding additional rules, such as requiring 0.y.0 to be a minor release rather than a major one. > > * A major release means something conforming to the new version may not conform to the previous version. This could mean removing rules, such as allowing any Unicode characters to be used in an identifier. Regardless of the fact that the maintainers of semver should provide the answer, I think you put it quite nicely. Nonetheless, I think you got minor and major mixed up –– which is what, I think, @jcornaz has been addressing. As I see it, the "feature - rule" analogy does not hold here, and, regardless, semvar specifications speak of a public API, not of "features". The addition of rules makes a specification more stringent; their removal makes it laxer. If you remove rules, what has hitherto conformed, conforms still. That's a minor change. If you add rules, what has hitherto conformed, might not conform with the new rules. That's a major change. So I'd have modified your interpretation thus: * A patch release means everything conforming to the previous version conforms to the new version. An obvious example would be fixing typos or rewording something without changing its meaning. * A minor release means everything conforming to the new version conforms to the previous version. This could mean removing rules (i.e. less MUSTs and MUST NOTs) or making them less stringent (MUST becomes a MAY). That would be, for example, allowing any Unicode characters to be used in an identifier (and not only ASCII alphanumerics and hyphens). * A major release means something conforming to the new version may not conform to the previous version. This could mean adding rules, such as a requirement that major patch identifiers must be even integers and that minor patch identifiers should be odd integers.

GiteaMirror commented

2026-06-13 13:09:09 -05:00

@jwdonahue commented on GitHub (May 3, 2022):

The current spec is most definitely not versioned using the SemVer rules. There have been numerous patch and minor level updates to the v2 spec over the years and they never bumped the version. This problem has been pointed out many times in the past. I think the best arguments against bumping the version number are:

No tooling changes have been required as a result of any of the updates, because:
What constitutes a SemVer 2 string has not changed.
Bumping the version number will create a great deal of consternation over whether Tool X.Y.Z can handle the latest version of SemVer string and increase support costs for tool maintainers.

Interpretation of SemVer semantics may have changed in minor ways due to the spec changes. Some things are clearer than they used to be. The addition of regexes to the spec has probably enabled better conformance for some tooling that missed some of the subtleties of the specification in the past.

@jwdonahue commented on GitHub (May 3, 2022): The current spec is most definitely not versioned using the SemVer rules. There have been numerous patch and minor level updates to the v2 spec over the years and they never bumped the version. This problem has been pointed out many times in the past. I think the best arguments against bumping the version number are: 1. No tooling changes have been required as a result of any of the updates, because: 2. What constitutes a SemVer 2 string has not changed. 3. Bumping the version number will create a great deal of consternation over whether Tool X.Y.Z can handle the latest version of SemVer string and increase support costs for tool maintainers. Interpretation of SemVer semantics may have changed in minor ways due to the spec changes. Some things are clearer than they used to be. The addition of regexes to the spec has probably enabled better conformance for some tooling that missed some of the subtleties of the specification in the past.

GiteaMirror commented

2026-06-13 13:09:09 -05:00

@jwdonahue commented on GitHub (May 3, 2022):

@Konotorious

A minor release means everything conforming to the new version conforms to the previous version. This could mean removing rules (i.e. less MUSTs and MUST NOTs) or making them less stringent (MUST becomes a MAY). That would be, for example, allowing any Unicode characters to be used in an identifier (and not only ASCII alphanumerics and hyphens).

Allowing Unicode characters would be a breaking change to the spec. Removing MUST or MUST NOT's is always a breaking change to a spec. In this example, it requires conforming tools to accept a wider range of inputs.

A minor change to a spec would be things like adding clarifying sentences or paragraphs, such as additional FAQ's.

@jwdonahue commented on GitHub (May 3, 2022): @Konotorious > A minor release means everything conforming to the new version conforms to the previous version. This could mean removing rules (i.e. less MUSTs and MUST NOTs) or making them less stringent (MUST becomes a MAY). That would be, for example, allowing any Unicode characters to be used in an identifier (and not only ASCII alphanumerics and hyphens). Allowing Unicode characters would be a breaking change to the spec. Removing MUST or MUST NOT's is always a breaking change to a spec. In this example, it requires conforming tools to accept a wider range of inputs. A minor change to a spec would be things like adding clarifying sentences or paragraphs, such as additional FAQ's.

GiteaMirror commented

2026-06-13 13:09:10 -05:00

@jcornaz commented on GitHub (May 3, 2022):

No tooling changes have been required as a result of any of the updates,

According to semver, only a major change would mean that it requires changes in tooling. If it has changed without requiring a tooling update, then it should have had patches or minor bumps.

What constitutes a SemVer 2 string has not changed.

The version string itself is only a small part of the spec. That argument is like saying: "I don't need to bump the version of my software because the file format has not changed"... If the versioning of the string format is really relevant, then it could have it's own versioning.

Bumping the version number will create a great deal of consternation over whether Tool X.Y.Z can handle the latest version of SemVer string and increase support costs for tool maintainers.

Yeah... sure. But I don't see how it is different than bumping the version of any widely used API. But more importantly, if semver is not good enough to version itself, I don't see how it could be good enough to version anything else.

Interpretation of SemVer semantics may have changed in minor ways due to the spec changes. Some things are clearer than they used to be. The addition of regexes to the spec has probably enabled better conformance for some tooling that missed some of the subtleties of the specification in the past.

If the interpretation of semantic versioning changes, that's quite a big deal. Sure depending on the change, it may be a patch or a minor bump. But not changing the version at all is plain wrong IMO.

@jcornaz commented on GitHub (May 3, 2022): > 1. No tooling changes have been required as a result of any of the updates, According to semver, only a major change would mean that it requires changes in tooling. If it has changed without requiring a tooling update, then it should have had patches or minor bumps. > 2. What constitutes a SemVer 2 string has not changed. The version string itself is only a small part of the spec. That argument is like saying: "I don't need to bump the version of my software because the file format has not changed"... If the versioning of the string format is really relevant, then it could have it's own versioning. > 3. Bumping the version number will create a great deal of consternation over whether Tool X.Y.Z can handle the latest version of SemVer string and increase support costs for tool maintainers. Yeah... sure. But I don't see how it is different than bumping the version of any widely used API. But more importantly, if semver is not good enough to version itself, I don't see how it could be good enough to version anything else. > Interpretation of SemVer semantics may have changed in minor ways due to the spec changes. Some things are clearer than they used to be. The addition of regexes to the spec has probably enabled better conformance for some tooling that missed some of the subtleties of the specification in the past. If the interpretation of *semantic* versioning changes, that's quite a big deal. Sure depending on the change, it may be a patch or a minor bump. But not changing the version at all is plain wrong IMO.

GiteaMirror commented

2026-06-13 13:09:10 -05:00

@jwdonahue commented on GitHub (May 3, 2022):

@jcornaz I agree with you. I was just stating my observations over that past decade or so have been that maintainers have used similar arguments in the past. This issue comes up all the time and goes nowhere.

@jwdonahue commented on GitHub (May 3, 2022): @jcornaz I agree with you. I was just stating my observations over that past decade or so have been that maintainers have used similar arguments in the past. This issue comes up all the time and goes nowhere.

GiteaMirror commented

2026-06-13 13:09:11 -05:00

@amacsmith commented on GitHub (Aug 21, 2025):

Lol I heard the guys over at Jira use spreadsheets 🤷‍♂️

@amacsmith commented on GitHub (Aug 21, 2025): Lol I heard the guys over at Jira use spreadsheets 🤷‍♂️

GiteaMirror commented

2026-06-13 13:09:12 -05:00

@nezmaka commented on GitHub (Sep 15, 2025):

@jwdonahue

Allowing Unicode characters would be a breaking change to the spec. Removing MUST or MUST NOT's is always a breaking change to a spec. In this example, it requires conforming tools to accept a wider range of inputs.

In what sense is the change breaking? Do you have a more concrete example?

As I see it, if you have a tool that conforms to the extra MUSTs, it would necessarily conform to the specs that lack them. The tool would break when, henceforward, a semver that ignores the old MUSTs comes in, but not when receiving the old conforming semvers. That is, it's compatible with what has come before but not necessarily with what comes in the future. That fits the major update description.

@nezmaka commented on GitHub (Sep 15, 2025): @jwdonahue > Allowing Unicode characters would be a breaking change to the spec. Removing MUST or MUST NOT's is always a breaking change to a spec. In this example, it requires conforming tools to accept a wider range of inputs. In what sense is the change breaking? Do you have a more concrete example? As I see it, if you have a tool that conforms to the extra MUSTs, it would necessarily conform to the specs that lack them. The tool would break when, henceforward, a semver that ignores the old MUSTs comes in, but not when receiving the old conforming semvers. That is, it's compatible with what has come before but not necessarily with what comes in the future. That fits the major update description.

GiteaMirror commented

2026-06-13 13:09:12 -05:00

@jwdonahue commented on GitHub (Sep 15, 2025):

@nezmaka

If the tools reject valid SemVer, then they are non-conforming. Any change to the spec, that renders an existing tool, non-conforming, is a breaking change. In addition, the development history of many of the packaging tools and package repositories, is such that they have always accepted non-conforming version strings of one form or another, but tend to drop all pretense of SemVer's semantics, when they fallback to older behaviors. That fallback behavior is based purely on syntax, so it's already ambiguous.

The net effect of any change, would have to be analyzed from the perspective of packaging tools and supporting infrastructure, SemVer sorting/selection algorithms, and SemVer string generators. Then there's the SemVer version disambiguation problem. We currently can't tell the difference between SemVer 1 beta, SemVer 1 and SemVer2.

Any non-patch level change to the spec, will require solving the SemVer version ambiguity issue that has existed ever since the adoption of SemVer 2, and that will be a breaking change, as it would likely require an additional tag.

@jwdonahue commented on GitHub (Sep 15, 2025): @nezmaka If the tools reject valid SemVer, then they are non-conforming. Any change to the spec, that renders an existing tool, non-conforming, is a breaking change. In addition, the development history of many of the packaging tools and package repositories, is such that they have always accepted non-conforming version strings of one form or another, but tend to drop all pretense of SemVer's semantics, when they fallback to older behaviors. That fallback behavior is based purely on syntax, so it's already ambiguous. The net effect of any change, would have to be analyzed from the perspective of packaging tools and supporting infrastructure, SemVer sorting/selection algorithms, and SemVer string generators. Then there's the SemVer version disambiguation problem. We currently can't tell the difference between SemVer 1 beta, SemVer 1 and SemVer2. Any non-patch level change to the spec, will require solving the SemVer version ambiguity issue that has existed ever since the adoption of SemVer 2, and that will be a breaking change, as it would likely require an additional tag.

GiteaMirror commented

2026-06-13 13:09:13 -05:00

@nezmaka commented on GitHub (Sep 15, 2025):

@jwdonahue

Ok, I see more clearly what you mean.
It seems to me that the source of the confusion is that SemVer is not a software and therefore provides an API only metaphorically.

If you have an application that parses SemVers then new patterns that conform to stricter rules would not cause trouble, while those that conform to laxer rules might.
The reverse is true for an application that generates SemVers. It itself would not break, but it would produce invalid SemVers if stricter rules have been implemented.

Is that a fair description?

@nezmaka commented on GitHub (Sep 15, 2025): @jwdonahue Ok, I see more clearly what you mean. It seems to me that the source of the confusion is that SemVer is not a software and therefore provides an API only metaphorically. If you have an application that parses SemVers then new patterns that conform to stricter rules would not cause trouble, while those that conform to laxer rules might. The reverse is true for an application that generates SemVers. It itself would not break, but it would produce invalid SemVers if stricter rules have been implemented. Is that a fair description?

GiteaMirror commented

2026-06-13 13:09:16 -05:00

@jwdonahue commented on GitHub (Sep 15, 2025):

That's the gist of it yes. Things would be simpler, if we had a declarative means, to label the version string's intended compliance levels.

@jwdonahue commented on GitHub (Sep 15, 2025): That's the gist of it yes. Things would be simpler, if we had a declarative means, to label the version string's intended compliance levels.

GiteaMirror commented

2026-06-13 13:09:16 -05:00

@jwdonahue commented on GitHub (Sep 15, 2025):

I would add that parsing isn't everything. You might not break a parser, but you could break a process that makes decisions, based on the specified semantics. But all that's on the tooling side. This thread appears to be all about how the spec is versioned, which to date, has not adhered to SemVer since the SemVer version got bumped from 1 something to 2.0.0. Bumping the version number on the spec is pointless, until we solve the disambiguation issue.

@jwdonahue commented on GitHub (Sep 15, 2025): I would add that parsing isn't everything. You might not break a parser, but you could break a process that makes decisions, based on the specified semantics. But all that's on the tooling side. This thread appears to be all about how the spec is versioned, which to date, has not adhered to SemVer since the SemVer version got bumped from 1 something to 2.0.0. Bumping the version number on the spec is pointless, until we solve the disambiguation issue.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#4770