github-starred/semver
2
0
Fork 0
mirror of https://github.com/semver/semver.git synced 2026-03-09 07:22:04 -05:00
Code Issues 118 Packages Projects Releases 4 Wiki Activity

BNF Grammar for Version #73

New Issue
Closed
opened 2026-02-17 11:08:41 -06:00 by GiteaMirror · 25 comments
GiteaMirror commented 2026-02-17 11:08:41 -06:00
Owner
Copy Link

Originally created by @petermichaux on GitHub (Jun 11, 2013).

Recently there has been confusion around what is allowed as a version. The standard is ambiguous. I propose including a BNF grammar for what is allowed. It is short and completely unambiguous so why not include it?

<version> ::= <major> "." <minor> "." <patch>
            | <major> "." <minor> "." <patch> "-" <pre-release>
            | <major> "." <minor> "." <patch> "+" <build>
            | <major> "." <minor> "." <patch> "-" <pre-release> "+" <build>

<major> ::= <non-negative integer>

<minor> ::= <non-negative integer>

<patch> ::= <non-negative integer>

<pre-release> ::= <dot-separated identifiers>

<build> ::= <dot-separated identifiers>

<dot-separated identifiers> ::= <identifier>
                              | <identifier> "." <dot-separated identifiers>

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

<identifier character> ::= <letter> | <digit> | "-"

<non-negative integer> ::= "0"
                         | <positive integer>

<positive integer> ::= <positive digit>
                     | <positive digit> <digits>

<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"
Originally created by @petermichaux on GitHub (Jun 11, 2013). Recently there has been confusion around what is allowed as a version. The standard is ambiguous. I propose including a BNF grammar for what is allowed. It is short and completely unambiguous so why not include it? ``` <version> ::= <major> "." <minor> "." <patch> | <major> "." <minor> "." <patch> "-" <pre-release> | <major> "." <minor> "." <patch> "+" <build> | <major> "." <minor> "." <patch> "-" <pre-release> "+" <build> <major> ::= <non-negative integer> <minor> ::= <non-negative integer> <patch> ::= <non-negative integer> <pre-release> ::= <dot-separated identifiers> <build> ::= <dot-separated identifiers> <dot-separated identifiers> ::= <identifier> | <identifier> "." <dot-separated identifiers> <identifier> ::= <identifier character> | <identifier character> <identifier> <identifier character> ::= <letter> | <digit> | "-" <non-negative integer> ::= "0" | <positive integer> <positive integer> ::= <positive digit> | <positive digit> <digits> <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-02-17 11:08:43 -06:00
Author
Owner
Copy Link

@petermichaux commented on GitHub (Jun 11, 2013):

Note that the grammar I have proposed does not allow major, minor, or patch to have unnecessary leading zeros. So major, minor, and patch can be 0, 1, 3200, etc but cannot be 00, 05, etc.

@petermichaux commented on GitHub (Jun 11, 2013): Note that the grammar I have proposed does not allow major, minor, or patch to have unnecessary leading zeros. So major, minor, and patch can be `0`, `1`, `3200`, etc but cannot be `00`, `05`, etc.
GiteaMirror commented 2026-02-17 11:08:43 -06:00
Author
Owner
Copy Link

@tbull commented on GitHub (Jun 11, 2013):

Note that the grammar I have proposed does not allow [..] unnecessary leading zeros.

That could be overcome with the following, provided we want that.

<non-negative integer> ::= <digits>

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

<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
@tbull commented on GitHub (Jun 11, 2013): > Note that the grammar I have proposed does not allow [..] unnecessary leading zeros. That could be overcome with the following, provided we want that. ``` <non-negative integer> ::= <digits> <digits> ::= <digit> | <digit> <digits> <digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ```
GiteaMirror commented 2026-02-17 11:08:44 -06:00
Author
Owner
Copy Link

@petermichaux commented on GitHub (Jun 11, 2013):

I think leading zeros are not desirable. They are not semantic. They are for manipulating automatic file listing order.

@petermichaux commented on GitHub (Jun 11, 2013): I think leading zeros are not desirable. They are not semantic. They are for manipulating automatic file listing order.
GiteaMirror commented 2026-02-17 11:08:45 -06:00
Author
Owner
Copy Link

@tbull commented on GitHub (Jun 11, 2013):

I have no opinion on that detail. My implementation allows leading zeroes.

One point against leading zeroes could be that there are some languages inspired by C that parse numbers starting with 0 as octal notation. This goes well so long as there are only digits 0 through 7 used, but fails if digits 8 or 9 show up. This is one common source of surprise for noobs to a language. On the other hand, I think, a spec should not take such language peculiarities into account.

One point for leading zeroes is that, if they are disallowed in major/minor/patch, they should be disallowed in numeric id parts of pre-release strings, too, and that would make matters even more complicated.

@tbull commented on GitHub (Jun 11, 2013): I have no opinion on that detail. My implementation allows leading zeroes. One point against leading zeroes could be that there are some languages inspired by C that parse numbers starting with `0` as octal notation. This goes well so long as there are only digits `0` through `7` used, but fails if digits `8` or `9` show up. This is one common source of surprise for noobs to a language. On the other hand, I think, a spec should not take such language peculiarities into account. One point _for_ leading zeroes is that, if they are disallowed in major/minor/patch, they should be disallowed in numeric id parts of pre-release strings, too, and that would make matters even more complicated.
GiteaMirror commented 2026-02-17 11:08:45 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 11, 2013):

YES. THIS. 👍

@isaacs commented on GitHub (Jun 11, 2013): YES. THIS. :+1:
GiteaMirror commented 2026-02-17 11:08:46 -06:00
Author
Owner
Copy Link

@petermichaux commented on GitHub (Jun 12, 2013):

A !JavaScript regular expression for this grammar is the following and could be included as non-normative bonus content since getting regular expressions correct is error prone. (This one should definitely be checked.)

/^([1-9]\d*)\.([1-9]\d*)\.([1-9]\d*)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/

The first capturing group is "major".

The second capturing group is "minor".

The third capturing group is "patch".

The forth capturing group is "pre-release" (not including the preceding dash delimiter between patch and pre-release).

The "build" is non-capturing because it is not to be used in any comparisons.

@petermichaux commented on GitHub (Jun 12, 2013): A !JavaScript regular expression for this grammar is the following and could be included as non-normative bonus content since getting regular expressions correct is error prone. (This one should definitely be checked.) ``` /^([1-9]\d*)\.([1-9]\d*)\.([1-9]\d*)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/ ``` The first capturing group is "major". The second capturing group is "minor". The third capturing group is "patch". The forth capturing group is "pre-release" (not including the preceding dash delimiter between patch and pre-release). The "build" is non-capturing because it is not to be used in any comparisons.
GiteaMirror commented 2026-02-17 11:08:47 -06:00
Author
Owner
Copy Link

@Tieske commented on GitHub (Jun 12, 2013):

imo leading zero's should be allowed, they don't do any harm (comparison is numerically), but might help out in sorting stuff easily.

I have little regex experience, but it seems to me that the regex fails on 10.10.10 as a version as zeros are not allowed at all. Besides that, I don't think the spec should include any regexes.

@Tieske commented on GitHub (Jun 12, 2013): imo leading zero's should be allowed, they don't do any harm (comparison is numerically), but might help out in sorting stuff easily. I have little regex experience, but it seems to me that the regex fails on `10.10.10` as a version as zeros are not allowed at all. Besides that, I don't think the spec should include any regexes.
GiteaMirror commented 2026-02-17 11:08:48 -06:00
Author
Owner
Copy Link

@petermichaux commented on GitHub (Jun 12, 2013):

> /^([1-9]\d*)\.([1-9]\d*)\.([1-9]\d*)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/.test('10.10.10')
true

In my experience, most developers are nervous and diffident when it comes to regular expressions. Including one as non-normative content could help ensure poor implementations do not appear. This will help the perceived integrity of the standard. It is optional, of course, but I think would be very helpful to have it in an easy to find location: right in the standard.

@petermichaux commented on GitHub (Jun 12, 2013): ``` > /^([1-9]\d*)\.([1-9]\d*)\.([1-9]\d*)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/.test('10.10.10') true ``` In my experience, most developers are nervous and diffident when it comes to regular expressions. Including one as non-normative content could help ensure poor implementations do not appear. This will help the perceived integrity of the standard. It is optional, of course, but I think would be very helpful to have it in an easy to find location: right in the standard.
GiteaMirror commented 2026-02-17 11:08:48 -06:00
Author
Owner
Copy Link

@haacked commented on GitHub (Jun 12, 2013):

@Tieske The /d* matches 0-9. The * means "0 or more". So this would match 10.10.10.

@haacked commented on GitHub (Jun 12, 2013): @Tieske The `/d*` matches `0-9`. The `*` means "0 or more". So this would match `10.10.10`.
GiteaMirror commented 2026-02-17 11:08:49 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 12, 2013):

Leading zeroes should not be allowed. It'd be confusing if 1.1.1 was the "same version" as 01.01.000001. Is this ambiguous in the language of the spec?

@isaacs commented on GitHub (Jun 12, 2013): Leading zeroes should not be allowed. It'd be confusing if `1.1.1` was the "same version" as `01.01.000001`. Is this ambiguous in the language of the spec?
GiteaMirror commented 2026-02-17 11:08:49 -06:00
Author
Owner
Copy Link

@petermichaux commented on GitHub (Jun 12, 2013):

Leading zeroes should not be allowed. It'd be confusing if 1.1.1 was the "same version" as 01.01.000001. Is this ambiguous in the language of the spec?

I agree. That is a good example.

@petermichaux commented on GitHub (Jun 12, 2013): > Leading zeroes should not be allowed. It'd be confusing if 1.1.1 was the "same version" as 01.01.000001. Is this ambiguous in the language of the spec? I agree. That is a good example.
GiteaMirror commented 2026-02-17 11:08:50 -06:00
Author
Owner
Copy Link

@tbull commented on GitHub (Jun 12, 2013):

It'd be confusing if 1.1.1 was the "same version" as 01.01.000001.

I don't see the point. What's so bad about that?

As to example rexgexp, certainly would hurt to include one as a non-normative example. There have several examples already been published somewhere in all the issues here.

@tbull commented on GitHub (Jun 12, 2013): > It'd be confusing if 1.1.1 was the "same version" as 01.01.000001. I don't see the point. What's so bad about that? As to example rexgexp, certainly would hurt to include one as a non-normative example. There have several examples already been published somewhere in all the issues here.
GiteaMirror commented 2026-02-17 11:08:51 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 12, 2013):

@tbull The versions look dramatically different. From the spec's point of view, they'd have the same precedence. However, it's strange and confusing to me that they're the same, when they apparently differ quite a bit.

Regardless, this definitely needs to be clarified in the specification.

@isaacs commented on GitHub (Jun 12, 2013): @tbull The versions look dramatically different. From the spec's point of view, they'd have the same precedence. However, it's strange and confusing to me that they're the same, when they apparently differ quite a bit. Regardless, this definitely needs to be clarified in the specification.
GiteaMirror commented 2026-02-17 11:08:51 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 12, 2013):

@petermichaux That regexp doesn't handle zeros in the main version portions.

Fixed to match the BNF you presented (which I believe is correct):

/^([1-9]\d*|0)\.([1-9]\d*|0)\.([1-9]\d*|0)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/
@isaacs commented on GitHub (Jun 12, 2013): @petermichaux That regexp doesn't handle zeros in the main version portions. Fixed to match the BNF you presented (which I believe is correct): ``` /^([1-9]\d*|0)\.([1-9]\d*|0)\.([1-9]\d*|0)(?:-([0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/ ```
GiteaMirror commented 2026-02-17 11:08:52 -06:00
Author
Owner
Copy Link

@petermichaux commented on GitHub (Jun 12, 2013):

Thanks, @isaacs. I did miss the zeros.

@petermichaux commented on GitHub (Jun 12, 2013): Thanks, @isaacs. I did miss the zeros.
GiteaMirror commented 2026-02-17 11:08:53 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 12, 2013):

Note for posterity: the BNF and regexp can be simplified somewhat if I'm overruled in #112.

@isaacs commented on GitHub (Jun 12, 2013): Note for posterity: the BNF and regexp can be simplified somewhat if I'm overruled in #112.
GiteaMirror commented 2026-02-17 11:08:53 -06:00
Author
Owner
Copy Link

@petermichaux commented on GitHub (Jun 13, 2013):

The regular expression could be appropriately included in "An implementers FAQ with normative and non-normative examples" mentioned in #113

@petermichaux commented on GitHub (Jun 13, 2013): The regular expression could be appropriately included in "An implementers FAQ with normative and non-normative examples" mentioned in #113
GiteaMirror commented 2026-02-17 11:08:54 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 14, 2013):

That BNF would allow leading zeroes in numeric prerelease identifiers, because "0009" is a valid set of "identifier characters".

Working on a more restrictive grammar now.

@isaacs commented on GitHub (Jun 14, 2013): That BNF would allow leading zeroes in numeric prerelease identifiers, because "0009" is a valid set of "identifier characters". Working on a more restrictive grammar now.
GiteaMirror commented 2026-02-17 11:08:54 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 14, 2013):

Disallowing leading zeroes on numeric identifiers.

Regexp:

/^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][a-zA-Z0-9-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][a-zA-Z0-9-]*))*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/

BNF:

<version> ::= <major> "." <minor> "." <patch>
            | <major> "." <minor> "." <patch> "-" <pre-release>
            | <major> "." <minor> "." <patch> "+" <build>
            | <major> "." <minor> "." <patch> "-" <pre-release> "+" <build>

<major> ::= <non-negative integer>

<minor> ::= <non-negative integer>

<patch> ::= <non-negative integer>

<pre-release> ::= <dot-separated identifiers>

<build> ::= <dot-separated identifiers>

<dot-separated identifiers> ::= <identifier>
                              | <identifier> "." <dot-separated identifiers>

<identifier> ::= <non-negative integer>
               | <non-numeric identifier>

<non-numeric identifier> ::= <letter>
                           | "-"
                           | <non-numeric identifier> <digits>
                           | <digits> <non-numeric identifier>

<identifier character> ::= <letter> | <digit> | "-"

<non-negative integer> ::= "0"
                         | <positive integer>

<positive integer> ::= <positive digit>
                     | <positive digit> <digits>

<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"
@isaacs commented on GitHub (Jun 14, 2013): Disallowing leading zeroes on numeric identifiers. Regexp: ``` /^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][a-zA-Z0-9-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][a-zA-Z0-9-]*))*))?(?:\+[0-9A-Za-z-]+(?:\.[0-9A-Za-z-]+)*)?$/ ``` BNF: ``` <version> ::= <major> "." <minor> "." <patch> | <major> "." <minor> "." <patch> "-" <pre-release> | <major> "." <minor> "." <patch> "+" <build> | <major> "." <minor> "." <patch> "-" <pre-release> "+" <build> <major> ::= <non-negative integer> <minor> ::= <non-negative integer> <patch> ::= <non-negative integer> <pre-release> ::= <dot-separated identifiers> <build> ::= <dot-separated identifiers> <dot-separated identifiers> ::= <identifier> | <identifier> "." <dot-separated identifiers> <identifier> ::= <non-negative integer> | <non-numeric identifier> <non-numeric identifier> ::= <letter> | "-" | <non-numeric identifier> <digits> | <digits> <non-numeric identifier> <identifier character> ::= <letter> | <digit> | "-" <non-negative integer> ::= "0" | <positive integer> <positive integer> ::= <positive digit> | <positive digit> <digits> <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-02-17 11:08:55 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 14, 2013):

Regular expression with comments:

var r = new RegExp(
  '^' +
  '(0|[1-9]\\d*)' + // major
  '\\.(0|[1-9]\\d*)' + // minor
  '\\.(0|[1-9]\\d*)' + // patch
  '(?:-' + // start prerelease
    '(' + // capture
      '(?:' + // first identifier
        '0|' + // 0, or
        '[1-9]\\d*|' + // numeric identifier, or
        '\\d*[a-zA-Z-][a-zA-Z0-9-]*' + // id with at least one non-number
      ')' + // end first identifier
      '(?:\\.' + // dot-separated
        '(?:0|[1-9]\\d*|\\d*[a-zA-Z-][a-zA-Z0-9-]*)' + // identifier
      ')*' + // zero or more of those
    ')' + // end prerelease capture
  ')?' + // prerelease is optional
  '(?:' + // build tag (non-capturing)
    '\\+[0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*' + // pretty much anything goes
  ')?' + // build tag is optional
  '$'
)
@isaacs commented on GitHub (Jun 14, 2013): Regular expression with comments: ``` javascript var r = new RegExp( '^' + '(0|[1-9]\\d*)' + // major '\\.(0|[1-9]\\d*)' + // minor '\\.(0|[1-9]\\d*)' + // patch '(?:-' + // start prerelease '(' + // capture '(?:' + // first identifier '0|' + // 0, or '[1-9]\\d*|' + // numeric identifier, or '\\d*[a-zA-Z-][a-zA-Z0-9-]*' + // id with at least one non-number ')' + // end first identifier '(?:\\.' + // dot-separated '(?:0|[1-9]\\d*|\\d*[a-zA-Z-][a-zA-Z0-9-]*)' + // identifier ')*' + // zero or more of those ')' + // end prerelease capture ')?' + // prerelease is optional '(?:' + // build tag (non-capturing) '\\+[0-9A-Za-z-]+(?:\\.[0-9A-Za-z-]+)*' + // pretty much anything goes ')?' + // build tag is optional '$' ) ```
GiteaMirror commented 2026-02-17 11:08:56 -06:00
Author
Owner
Copy Link

@mojombo commented on GitHub (Jun 14, 2013):

I'm in favor of a BNF grammar in the spec. As SemVer gains adoption, and especially as tools rely on well-formed versions, it will be critical that no ambiguity exists. Seems fine to put it in the main spec rather than an appendix. One page to rule them all.

@mojombo commented on GitHub (Jun 14, 2013): I'm in favor of a BNF grammar in the spec. As SemVer gains adoption, and especially as tools rely on well-formed versions, it will be critical that no ambiguity exists. Seems fine to put it in the main spec rather than an appendix. One page to rule them all.
GiteaMirror commented 2026-02-17 11:08:56 -06:00
Author
Owner
Copy Link

@petermichaux commented on GitHub (Jun 14, 2013):

@isaacs I believe the following part of your BNF is incorrect. You don't allow aa, --, or a1a, for example. You don't use <identifier character> at all.

<non-numeric identifier> ::= <letter>
                           | "-"
                           | <non-numeric identifier> <digits>
                           | <digits> <non-numeric identifier>

<identifier character> ::= <letter> | <digit> | "-"

I think it should be

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

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

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

<identifier character> ::= <non-digit character> | <digit>
@petermichaux commented on GitHub (Jun 14, 2013): @isaacs I believe the following part of your BNF is incorrect. You don't allow `aa`, `--`, or `a1a`, for example. You don't use `<identifier character>` at all. ``` <non-numeric identifier> ::= <letter> | "-" | <non-numeric identifier> <digits> | <digits> <non-numeric identifier> <identifier character> ::= <letter> | <digit> | "-" ``` I think it should be ``` <non-numeric identifier> ::= <non-digit character> | <non-digit character> <identifier> | <identifier> <non-digit character> | <identifier> <non-digit character> <identifier> <identifier> ::= <identifier character> | <identifier character> <identifier> <non-digit character> ::= <letter> | "-" <identifier character> ::= <non-digit character> | <digit> ```
GiteaMirror commented 2026-02-17 11:08:57 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 14, 2013):

Yes, that is correct, thanks. My regexp-fu greatly exceeds my bnf-fu :)

@isaacs commented on GitHub (Jun 14, 2013): Yes, that is correct, thanks. My regexp-fu greatly exceeds my bnf-fu :)
GiteaMirror commented 2026-02-17 11:08:58 -06:00
Author
Owner
Copy Link

@isaacs commented on GitHub (Jun 14, 2013):

@mojombo Great, thanks for the direction. Patch submitted in #116.

Seems fine to put it in the main spec rather than an appendix. One page to rule them all.

I absolutely agree about the BNF grammar, since that's part of the "specification" bit. How would you feel about adding example pseudocode and/or authoritative test cases as separate pages, or even just separate files in this repo that don't show up on the website at all? I'd like them to be included for clarity, but the concern is that the page could get too unwieldy.

@isaacs commented on GitHub (Jun 14, 2013): @mojombo Great, thanks for the direction. Patch submitted in #116. > Seems fine to put it in the main spec rather than an appendix. One page to rule them all. I absolutely agree about the BNF grammar, since that's part of the "specification" bit. How would you feel about adding example pseudocode and/or authoritative test cases as separate pages, or even just separate files in this repo that don't show up on the website at all? I'd like them to be included for clarity, but the concern is that the page could get too unwieldy.
GiteaMirror commented 2026-02-17 11:08:58 -06:00
Author
Owner
Copy Link

@EddieGarmon commented on GitHub (Jun 18, 2013):

A proposed simplified and descriptive update to the BNF.
isaacs#1

@EddieGarmon commented on GitHub (Jun 18, 2013): A proposed simplified and descriptive update to the BNF. isaacs#1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
consensus seeking
duplicate
extend
layout
pull-request
Mirrored from GitHub Pull Request
 question
RFC
spelling/grammar
staled
update
waiting for PR
won't fix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/semver#73
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?