[GH-ISSUE #254] Specify character set to use in versioning. #2893

New Issue

GiteaMirror · 2026-04-25T17:00:45-05:00

GiteaMirror commented

2026-04-25 17:00:45 -05:00

Originally created by @travis-a-hoffman on GitHub (May 19, 2015).
Original GitHub issue: https://github.com/semver/semver/issues/254

Currently, the specification implicitly specifies what character set is to be used for the versioning names. In an increasingly I8N world, this may not be a fair assumption. Most will assume ASCII is to be used, however, explicitly specifying the legal characters will make it easier for authors writing tools based on this spec.

An initial cut would simply state something like:

Only '.' (ASCII 0x2E) may be used as the separator for major.minor.patch, and that only '0'-'9' (ASCII 0x30 through 0x39) may be used as number values. For the extended portion, a single '-' (ASCII 0x2D) is used to indicate the start of an extended version. It may or may not be desirable to specify the character set of the extended version part. Not doing so would implicitly let others use extended character sets. I'm happy to leave that as a judgement call by the spec definer.

Originally created by @travis-a-hoffman on GitHub (May 19, 2015). Original GitHub issue: https://github.com/semver/semver/issues/254 Currently, the specification implicitly specifies what character set is to be used for the versioning names. In an increasingly I8N world, this may not be a fair assumption. Most will assume ASCII is to be used, however, explicitly specifying the legal characters will make it easier for authors writing tools based on this spec. An initial cut would simply state something like: Only '.' (ASCII 0x2E) may be used as the separator for major.minor.patch, and that only '0'-'9' (ASCII 0x30 through 0x39) may be used as number values. For the extended portion, a single '-' (ASCII 0x2D) is used to indicate the start of an extended version. It may or may not be desirable to specify the character set of the extended version part. Not doing so would implicitly let others use extended character sets. I'm happy to leave that as a judgement call by the spec definer.

GiteaMirror closed this issue

2026-04-25 17:00:45 -05:00

GiteaMirror commented

2026-04-25 17:00:46 -05:00

@travis-a-hoffman commented on GitHub (May 19, 2015):

🤦 ... I should have read more closely. I would like to amend this to make the character set "more prominent", and to specify they numbers are to be base 10 only. By the spec, number bases 1-9 are all valid number bases in the version numbers.

@travis-a-hoffman commented on GitHub (May 19, 2015): :facepalm: ... I should have read more closely. I would like to amend this to make the character set "more prominent", and to specify they numbers are to be base 10 only. By the spec, number bases 1-9 are all valid number bases in the version numbers.

GiteaMirror commented

2026-04-25 17:00:47 -05:00

@hakanai commented on GitHub (Jun 24, 2015):

If I did use base 9 version numbers, what would be the problem? Ordering would still work sensibly and the only thing people would notice is skipping a release every now and then.

(Note that I wouldn't do this, but I would have considered using dozenal, because dozenal is great.)

@hakanai commented on GitHub (Jun 24, 2015): If I did use base 9 version numbers, what would be the problem? Ordering would still work sensibly and the only thing people would notice is skipping a release every now and then. (Note that I wouldn't do this, but I would have considered using dozenal, because dozenal is great.)

GiteaMirror commented

2026-04-25 17:00:47 -05:00

@sparr commented on GitHub (Dec 3, 2015):

@travis-a-hoffman is there something in the spec forbidding bases higher than 10, other than the 1.9.0 -> 1.10.0 -> 1.11.0 example?

@sparr commented on GitHub (Dec 3, 2015): @travis-a-hoffman is there something in the spec forbidding bases higher than 10, other than the `1.9.0 -> 1.10.0 -> 1.11.0` example?

GiteaMirror commented

2026-04-25 17:00:48 -05:00

@FichteFoll commented on GitHub (Dec 3, 2015):

@sparr How would you represent that number?

Technically, the spec does not limit you to use only digit characters for "integers", doesn't define their ASCII/unicode codes and does not define what "numeric" means. Afaics.

@FichteFoll commented on GitHub (Dec 3, 2015): @sparr How would you represent that number? Technically, the spec does not limit you to use only digit characters for "integers", doesn't define their ASCII/unicode codes and does not define what "numeric" means. Afaics.

GiteaMirror commented

2026-04-25 17:00:48 -05:00

@sparr commented on GitHub (Dec 3, 2015):

@FichteFoll I ended up here after a discussion elsewhere about whether or not 0.C (0.8 -> 0.9 -> 0.A -> 0.B -> 0.C) is a valid semver version number. Of course it's not because it's missing the third part, but we were specifically discussing C vs 12

@sparr commented on GitHub (Dec 3, 2015): @FichteFoll I ended up here after a discussion elsewhere about whether or not 0.C (0.8 -> 0.9 -> 0.A -> 0.B -> 0.C) is a valid semver version number. Of course it's not because it's missing the third part, but we were specifically discussing `C` vs `12`

GiteaMirror commented

2026-04-25 17:00:49 -05:00

@hakanai commented on GitHub (Dec 4, 2015):

Well C is right out now, isn't it.

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

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

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

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

@hakanai commented on GitHub (Dec 4, 2015): Well `C` is right out now, isn't it. ``` <numeric identifier> ::= "0" | <positive digit> | <positive digit> <digits> <digits> ::= <digit> | <digit> <digits> <digit> ::= "0" | <positive digit> <positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ```

GiteaMirror commented

2026-04-25 17:00:50 -05:00

@sparr commented on GitHub (Dec 4, 2015):

@trejkaz thanks for pointing that out. the BNF definition isn't on the main website. I didn't realize this repo contained additional info of that sort.

@sparr commented on GitHub (Dec 4, 2015): @trejkaz thanks for pointing that out. the BNF definition isn't on the main website. I didn't realize this repo contained additional info of that sort.

GiteaMirror commented

2026-04-25 17:00:50 -05:00

@FichteFoll commented on GitHub (Dec 4, 2015):

From what I understand, the BNF was modeled after the spec and made some assumptions that can't necessarily be assumed to hold true just from the spec itself. If the BNF was part of the spec however, it would make clear what characters are allowed and what are not.
(Currently, this is only the case for metadata and prereleases since there is a regex set in the spec for them.)

@FichteFoll commented on GitHub (Dec 4, 2015): From what I understand, the BNF was modeled after the spec and made some assumptions that can't necessarily be assumed to hold true just from the spec itself. If the BNF was part of the spec however, it would make clear what characters are allowed and what are not. (Currently, this is only the case for metadata and prereleases since there is a regex set in the spec for them.)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2893