Originally created by @DannyS712 on GitHub (May 24, 2020).
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers
immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII
alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored
when determining version precedence. Thus two versions that differ only in the build metadata, have the
same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
The explanation that
two versions that differ only in the build metadata, have the same precedence
is followed by examples that differ in build metadata, but do not have same precedence, because the first and third examples are pre-release versions and thus have lower precedence.
I suggest replacing the examples that include both pre-release and build metadata information with clearer examples that only have build metadata,
Originally created by @DannyS712 on GitHub (May 24, 2020).
```
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers
immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII
alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored
when determining version precedence. Thus two versions that differ only in the build metadata, have the
same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
```
The explanation that
> two versions that differ only in the build metadata, have the same precedence
is followed by examples that differ in build metadata, but do **not** have same precedence, because the first and third examples are pre-release versions and thus have lower precedence.
I suggest replacing the examples that include both pre-release and build metadata information with clearer examples that only have build metadata,
I don't think those examples were intended to be limited to just the last sentence. They are just a few random samples of build meta usage.
@jwdonahue commented on GitHub (Jun 9, 2020):
I don't think those examples were intended to be limited to just the last sentence. They are just a few random samples of build meta usage.
Additionally, 1.0.0-beta+exp.sha.5114f85 does not meet the bnf specification. Specifically, the build identifier5114f85 is neither alphanumeric identifier nor digits.
Also, 1.0.0+21AF26D3----117B344092BD does not meet the bnf specification. Specifically, the build identifier117B344092BD is neither alphanumeric identifier nor digits.
@chonton commented on GitHub (May 15, 2023):
Additionally, **1.0.0-beta+exp.sha.5114f85** does not meet the bnf specification. Specifically, the **build identifier** `5114f85` is neither **alphanumeric identifier** nor **digits**.
Also, **1.0.0+21AF26D3----117B344092BD** does not meet the bnf specification. Specifically, the **build identifier** `117B344092BD` is neither **alphanumeric identifier** nor **digits**.
@chonton, specifically which character(s) in those strings are neither alpha or numeric? Were they encoded incorrectly?
I don't see the problem.
@jwdonahue commented on GitHub (May 16, 2023):
@chonton, specifically which character(s) in those strings are neither alpha or numeric? Were they encoded incorrectly?
I don't see the problem.
I got it wrong. The build identifier cannot be digits, since it does not consist only of digit. It can be alphanumeric identifier. What confused me is that I cannot determine the difference between digits and alphanumeric identifier until the next '.' or end of input.
@chonton commented on GitHub (May 16, 2023):
I got it wrong. The build identifier cannot be **digits**, since it does not consist only of **digit**. It can be **alphanumeric identifier**. What confused me is that I cannot determine the difference between **digits** and **alphanumeric identifier** until the next '.' or end of input.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @DannyS712 on GitHub (May 24, 2020).
The explanation that
is followed by examples that differ in build metadata, but do not have same precedence, because the first and third examples are pre-release versions and thus have lower precedence.
I suggest replacing the examples that include both pre-release and build metadata information with clearer examples that only have build metadata,
@jwdonahue commented on GitHub (Jun 9, 2020):
I don't think those examples were intended to be limited to just the last sentence. They are just a few random samples of build meta usage.
@chonton commented on GitHub (May 15, 2023):
Additionally, 1.0.0-beta+exp.sha.5114f85 does not meet the bnf specification. Specifically, the build identifier
5114f85is neither alphanumeric identifier nor digits.Also, 1.0.0+21AF26D3----117B344092BD does not meet the bnf specification. Specifically, the build identifier
117B344092BDis neither alphanumeric identifier nor digits.@jwdonahue commented on GitHub (May 16, 2023):
@chonton, specifically which character(s) in those strings are neither alpha or numeric? Were they encoded incorrectly?
I don't see the problem.
@chonton commented on GitHub (May 16, 2023):
I got it wrong. The build identifier cannot be digits, since it does not consist only of digit. It can be alphanumeric identifier. What confused me is that I cannot determine the difference between digits and alphanumeric identifier until the next '.' or end of input.