Restrict "integers" to ASCII #249

New Issue

GiteaMirror · 2026-02-17T11:41:13-06:00

GiteaMirror commented

2026-02-17 11:41:13 -06:00

Originally created by @ogregoire on GitHub (Nov 9, 2016).

Currently, only the "free" texts is restricted to ASCII (in pre-release and build parts).

As far as I know, there are unicode digits that can form integers in other number ranges than [0-9]: http://www.fileformat.info/info/unicode/category/Nd/list.htm

So currently a version like ꩑.꧒.᮳ (U+AA51 + . + U+A9D2 + . + U+1BB3) is valid and can be understood as the same as 1.2.3.

The various problems with this are that:

they are not "universally legible" as a hidden requirement expressed in issue #121. To be honest, I can't even read them in my browser.
𝟏.𝟐.𝟑 is more legible for us westerners, but it's not ASCII, and therefore barely parseable without any proper unicode library.
the first example (꩑.꧒.᮳) uses three different scripts to express integers: CHAM DIGIT ONE, JAVANESE DIGIT TWO and SUNDANESE DIGIT THREE and is still valid, because these digits, individually, still express "integer" numbers.

To avoid such problems, please consider restricting the definition of integers to ASCII characters as well.

Originally created by @ogregoire on GitHub (Nov 9, 2016). Currently, only the "free" texts is restricted to ASCII (in pre-release and build parts). As far as I know, there are unicode digits that can form integers in other number ranges than `[0-9]`: http://www.fileformat.info/info/unicode/category/Nd/list.htm So currently a version like `꩑.꧒.᮳` (`U+AA51` + `.` + `U+A9D2` + `.` + `U+1BB3`) is valid and can be understood as the same as `1.2.3`. The various problems with this are that: 1. they are not "universally legible" as a hidden requirement expressed in issue #121. To be honest, I can't even read them in my browser. 2. `𝟏.𝟐.𝟑` is more legible for us westerners, but it's not ASCII, and therefore barely parseable without any proper unicode library. 3. the first example (`꩑.꧒.᮳`) uses three *different* scripts to express integers: `CHAM DIGIT ONE`, `JAVANESE DIGIT TWO` and `SUNDANESE DIGIT THREE` and is still valid, because these digits, individually, still express "integer" numbers. To avoid such problems, please consider restricting the definition of integers to ASCII characters as well.

GiteaMirror closed this issue

2026-02-17 11:41:14 -06:00

GiteaMirror commented

2026-02-17 11:41:15 -06:00

@ogregoire commented on GitHub (Nov 9, 2016):

Damn, I wrote this based on the spec at semver.org, not based on the latest semver.md file, which include a BNF that remove this possibility.

It's probably a good idea to update semver.org to entirely reflect this repository.

@ogregoire commented on GitHub (Nov 9, 2016): Damn, I wrote this based on the spec at semver.org, not based on the latest `semver.md` file, which include a BNF that remove this possibility. It's probably a good idea to update semver.org to entirely reflect this repository.

GiteaMirror commented

2026-02-17 11:41:16 -06:00

@Kotolegokot commented on GitHub (Jan 8, 2017):

This issue should probably be closed now

@Kotolegokot commented on GitHub (Jan 8, 2017): This issue should probably be closed now

GiteaMirror referenced this issue

2026-02-17 12:18:48 -06:00

[PR #296] Slightly clarify the build metadata section #780

Sign in to join this conversation.