[GH-ISSUE #231] What the difference between semver 1 and 2 ? #6147

New Issue

GiteaMirror · 2026-06-17T04:44:15-05:00

GiteaMirror commented

2026-06-17 04:44:15 -05:00

Originally created by @ghost on GitHub (Nov 8, 2014).
Original GitHub issue: https://github.com/semver/semver/issues/231

What the difference between semver 1 and 2 ?

Where is semver 1 scheme like https://github.com/mojombo/semver/blob/master/semver.md and https://github.com/mojombo/semver/blob/master/semver.svg for semver 2?

Originally created by @ghost on GitHub (Nov 8, 2014). Original GitHub issue: https://github.com/semver/semver/issues/231 What the difference between semver 1 and 2 ? Where is semver 1 scheme like https://github.com/mojombo/semver/blob/master/semver.md and https://github.com/mojombo/semver/blob/master/semver.svg for semver 2?

GiteaMirror added the question label 2026-06-17 04:44:15 -05:00

GiteaMirror closed this issue

2026-06-17 04:44:16 -05:00

GiteaMirror commented

2026-06-17 04:44:19 -05:00

@dvorapa commented on GitHub (Nov 8, 2014):

The difference is here: https://github.com/mojombo/semver/compare/v1.0.0...v2.0.0
If I understand you correctly, then the spec of v1.0.0 is here: https://github.com/mojombo/semver/blob/v1.0.0/semver.md
If I understand you correctly, then there was no svg scheme or backus–naur form in v1.0.0 version. They both were added after v2.0.0 was released.

P.S.: The difference between v2.0.0 and current draft (master) is here: https://github.com/mojombo/semver/compare/v2.0.0...master and the difference between v1.0.0 and current draft (master) here: https://github.com/mojombo/semver/compare/v1.0.0...master

@dvorapa commented on GitHub (Nov 8, 2014): 1. The difference is here: https://github.com/mojombo/semver/compare/v1.0.0...v2.0.0 2. If I understand you correctly, then the spec of v1.0.0 is here: https://github.com/mojombo/semver/blob/v1.0.0/semver.md 3. If I understand you correctly, then there was no svg scheme or backus–naur form in v1.0.0 version. They both were added after v2.0.0 was released. P.S.: The difference between v2.0.0 and current draft (master) is here: https://github.com/mojombo/semver/compare/v2.0.0...master and the difference between v1.0.0 and current draft (master) here: https://github.com/mojombo/semver/compare/v1.0.0...master

GiteaMirror commented

2026-06-17 04:44:19 -05:00

@ghost commented on GitHub (Nov 8, 2014):

no
i saw it
yes. any plans to make it? or is it correct?

Backus–Naur Form Grammar for Valid SemVer v1 Versions

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release identifier>

<version core> ::= <major> "." <minor> "." <patch>

<major> ::= <numeric identifier>

<minor> ::= <numeric identifier>

<patch> ::= <numeric identifier>

<pre-release identifier> ::= <alphanumeric identifier>
                           | <numeric identifier>

<alphanumeric identifier> ::= <non-digit>
                            | <non-digit> <identifier characters>
                            | <identifier characters> <non-digit>
                            | <identifier characters> <non-digit> <identifier characters>

<numeric identifier> ::= "0"
                       | <positive digit>
                       | <positive digit> <digits>

<identifier characters> ::= <identifier character>
                          | <identifier character> <identifier characters>

<identifier character> ::= <digit>
                         | <non-digit>

<non-digit> ::= <letter>
              | "-"

<digits> ::= <digit>
           | <digit> <digits>

<digit> ::= "0"
          | <positive digit>

<positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"

<letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J"
           | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T"
           | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d"
           | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n"
           | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x"
           | "y" | "z"

@ghost commented on GitHub (Nov 8, 2014): 1. no 2. i saw it 3. yes. any plans to make it? or is it correct? > ## Backus–Naur Form Grammar for Valid SemVer v1 Versions > > ``` > <valid semver> ::= <version core> > | <version core> "-" <pre-release identifier> > > <version core> ::= <major> "." <minor> "." <patch> > > <major> ::= <numeric identifier> > > <minor> ::= <numeric identifier> > > <patch> ::= <numeric identifier> > > <pre-release identifier> ::= <alphanumeric identifier> > | <numeric identifier> > > <alphanumeric identifier> ::= <non-digit> > | <non-digit> <identifier characters> > | <identifier characters> <non-digit> > | <identifier characters> <non-digit> <identifier characters> > > <numeric identifier> ::= "0" > | <positive digit> > | <positive digit> <digits> > > <identifier characters> ::= <identifier character> > | <identifier character> <identifier characters> > > <identifier character> ::= <digit> > | <non-digit> > > <non-digit> ::= <letter> > | "-" > > <digits> ::= <digit> > | <digit> <digits> > > <digit> ::= "0" > | <positive digit> > > <positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" > > <letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" > | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" > | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" > | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" > | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" > | "y" | "z" > ```

GiteaMirror commented

2026-06-17 04:44:20 -05:00

@dvorapa commented on GitHub (Nov 8, 2014):

Could I ask why do you want to use v1.0.0 instead of v2.0.0? Because I think, that making backus–naur form for obsolete version is pointless and time-consuming. Therefore I think there aren't any plans for doing it, but you could try to create backus-naur form and svg scheme on your own, fork v1.0.0, add it there and make a pull request if you have a time to spare.

@dvorapa commented on GitHub (Nov 8, 2014): Could I ask why do you want to use v1.0.0 instead of v2.0.0? Because I think, that making backus–naur form for obsolete version is pointless and time-consuming. Therefore I think there aren't any plans for doing it, but you could try to create backus-naur form and svg scheme on your own, fork v1.0.0, add it there and make a pull request if you have a time to spare.

GiteaMirror commented

2026-06-17 04:44:21 -05:00

@ghost commented on GitHub (Nov 9, 2014):

i want understand difference between 1 and 2

@ghost commented on GitHub (Nov 9, 2014): i want understand difference between 1 and 2

GiteaMirror commented

2026-06-17 04:44:22 -05:00

@ghost commented on GitHub (Nov 9, 2014):

ah....
Is added notations is correct?
How i can pull it to repoif i do not know it?

@ghost commented on GitHub (Nov 9, 2014): ah.... Is added notations is correct? How i can pull it to repoif i do not know it?

GiteaMirror commented

2026-06-17 04:44:22 -05:00

@anarcat commented on GitHub (May 22, 2015):

it's kind of hilarious that semver.org doesn't document those changes while the document itself is pretty strict about documenting those changes itself... :p

to answer the actual question here, it seems most of the changes are:

addition of the Summary section on top
some clarifications and small fixes
leading zeros are not accepted
minor version numbers MUST be incremented if API is marked as deprecated
the SemVerTag header is removed and the content is clarified
precedence rules have been added
build metadata (+something) has been added
some FAQs were added

I suggest something like that be added to the FAQ.

@anarcat commented on GitHub (May 22, 2015): it's kind of hilarious that semver.org doesn't document those changes while the document itself is pretty strict about documenting those changes itself... :p to answer the actual question here, it seems most of the changes are: - addition of the `Summary` section on top - some clarifications and small fixes - leading zeros are not accepted - minor version numbers MUST be incremented if API is marked as deprecated - the SemVerTag header is removed and the content is clarified - precedence rules have been added - build metadata (`+something`) has been added - some FAQs were added I suggest something like that be added to the FAQ.

GiteaMirror commented

2026-06-17 04:44:23 -05:00

@EddieGarmon commented on GitHub (May 22, 2015):

it's kind of hilarious that semver.org doesn't document those changes while the document itself is pretty strict about documenting those changes itself... :p

SemVer is about documenting the API, not the deltas between the releases.

@EddieGarmon commented on GitHub (May 22, 2015): > it's kind of hilarious that semver.org doesn't document those changes while the document itself is pretty strict about documenting those changes itself... :p SemVer is about documenting the API, not the deltas between the releases.

GiteaMirror commented

2026-06-17 04:44:24 -05:00

@jeremyfrench commented on GitHub (Feb 9, 2017):

Perhaps being pedantic here, but is semVer 2.0.0 breaking backwards compatibility? Why is it 2.0.0 not 1.1.0 ?

@jeremyfrench commented on GitHub (Feb 9, 2017): Perhaps being pedantic here, but is semVer 2.0.0 breaking backwards compatibility? Why is it 2.0.0 not 1.1.0 ?

GiteaMirror commented

2026-06-17 04:44:25 -05:00

@FichteFoll commented on GitHub (Feb 9, 2017):

It is, specifically because of

leading zeros are not accepted

minor version numbers MUST be incremented if API is marked as deprecated

@FichteFoll commented on GitHub (Feb 9, 2017): It is, specifically because of > - leading zeros are not accepted > - minor version numbers MUST be incremented if API is marked as deprecated

GiteaMirror commented

2026-06-17 04:44:25 -05:00

@jwdonahue commented on GitHub (Dec 8, 2017):

The addition of build metadata is also a breaking change from SemVer 1.0.0 because there were/are no specified means to extend the string without updating the standard itself. In other words, SemVer is not extensible. Also, build metadata added the plus symbol to the spec, which is known to break some implementations that implement SemVer. Essentially, any string which has embedded in it, what would otherwise be a legal SemVer string if standing alone, is not a SemVer compliant string.

@jwdonahue commented on GitHub (Dec 8, 2017): The addition of build metadata is also a breaking change from SemVer 1.0.0 because there were/are no specified means to extend the string without updating the standard itself. In other words, SemVer is not extensible. Also, build metadata added the plus symbol to the spec, which is known to break some implementations that implement SemVer. Essentially, any string which has embedded in it, what would otherwise be a legal SemVer string if standing alone, is not a SemVer compliant string.

GiteaMirror commented

2026-06-17 04:44:26 -05:00

@jwdonahue commented on GitHub (Dec 8, 2017):

@ggrnd0, unless you have any further questions, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 8, 2017): @ggrnd0, unless you have any further questions, please close this issue at your earliest possible convenience.

GiteaMirror commented

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

@FichteFoll commented on GitHub (Dec 9, 2017):

What you are talking about is forwards compatibility. The addition of the metadata section adds a new feature but it is backwards compatible because any 1.0.0 version without a metadata section (and without violating any of the breaking changes I quoted) is still valid in 2.0.0.

If just the metadata section was added, this could have been released as 1.1.0.

@FichteFoll commented on GitHub (Dec 9, 2017): What you are talking about is forwards compatibility. The addition of the metadata section adds a new feature but it is backwards compatible because any 1.0.0 version without a metadata section (and without violating any of the breaking changes I quoted) is still valid in 2.0.0. If just the metadata section was added, this could have been released as 1.1.0.

GiteaMirror commented

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

@anarcat commented on GitHub (Dec 10, 2017):

@ggrnd0, unless you have any further questions, please close this issue at your earliest possible convenience.

Would the authors here welcome pull requests that would integrate the above documentation (https://github.com/semver/semver/issues/231#issuecomment-104478395) in the source somehow? shouldn't there be a CHANGELOG that would summarize major changes in the releases?

or could the release tags include those detailed changes?

thanks!

@anarcat commented on GitHub (Dec 10, 2017): > @ggrnd0, unless you have any further questions, please close this issue at your earliest possible convenience. Would the authors here welcome pull requests that would integrate the above documentation (https://github.com/semver/semver/issues/231#issuecomment-104478395) in the source somehow? shouldn't there be a CHANGELOG that would summarize major changes in the releases? or could the release tags include those detailed changes? thanks!

GiteaMirror commented

2026-06-17 04:44:28 -05:00

@jwdonahue commented on GitHub (Dec 12, 2017):

@FichteFoll, a non-breaking change to the spec would not break existing parsers. When metadata was added, it broke existing parsers. That change alone was sufficient to bump from 1.0.0 to 2.0.0.

@ggrnd0, you are always welcome to submit PR's. How welcome that might be will be depend on the details. Are proposing adding a change log with retro-active entries? You could always add a page to the wiki that documents the aspects you can identify that are different. Then others can come along and refine it as needed.

@jwdonahue commented on GitHub (Dec 12, 2017): @FichteFoll, a non-breaking change to the spec would not break existing parsers. When metadata was added, it broke existing parsers. That change alone was sufficient to bump from 1.0.0 to 2.0.0. @ggrnd0, you are always welcome to submit PR's. How welcome that might be will be depend on the details. Are proposing adding a change log with retro-active entries? You could always add a page to the wiki that documents the aspects you can identify that are different. Then others can come along and refine it as needed.

GiteaMirror commented

2026-06-17 04:44:29 -05:00

@jwdonahue commented on GitHub (Dec 12, 2017):

@ggrnd0, in any case, this issue should either be closed or pending a PR. The wiki page won't require the PR process. We can refine it and maybe eventually add a log file to the site? It's up to you. I don't have the bandwidth to complete that task and you seem to be the only person with the motivation at this point.

@jwdonahue commented on GitHub (Dec 12, 2017): @ggrnd0, in any case, this issue should either be closed or pending a PR. The wiki page won't require the PR process. We can refine it and maybe eventually add a log file to the site? It's up to you. I don't have the bandwidth to complete that task and you seem to be the only person with the motivation at this point.

GiteaMirror commented

2026-06-17 04:44:30 -05:00

@WalkerCodeRanger commented on GitHub (Jan 8, 2020):

leading zeros are not accepted

It should be noted that this is not just in major, minor, and patch. It also applies to the pre-release version number. In the v1 spec, "denoted by appending an arbitrary string immediately following the patch version and a dash. The string MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-]." In the v2 spec, "denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes."

The way I read that, it also means that previously "1.2.3-" was a valid version number with an empty pre-release version, but is no longer valid.

@WalkerCodeRanger commented on GitHub (Jan 8, 2020): > * leading zeros are not accepted It should be noted that this is not just in major, minor, and patch. It also applies to the pre-release version number. In the v1 spec, "denoted by appending an arbitrary string immediately following the patch version and a dash. The string MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-]." In the v2 spec, "denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes." The way I read that, it also means that previously "1.2.3-" was a valid version number with an empty pre-release version, but is no longer valid.

GiteaMirror commented

2026-06-17 04:44:30 -05:00

@alexandrtovmach commented on GitHub (Jun 10, 2020):

Closed as resolved, thanks everyone for contribution 👍
@ggrnd0 If you still have any questions, feel free to re-open

@alexandrtovmach commented on GitHub (Jun 10, 2020): Closed as resolved, thanks everyone for contribution :+1: @ggrnd0 If you still have any questions, feel free to re-open

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6147