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.
@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.
<!-- gh-comment-id:103685378 -->
@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.
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.)
<!-- gh-comment-id:114761003 -->
@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.)
@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?
<!-- gh-comment-id:161786645 -->
@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?
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.
<!-- gh-comment-id:161794555 -->
@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 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
<!-- gh-comment-id:161797167 -->
@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`
@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.
<!-- gh-comment-id:161888067 -->
@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.
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.)
<!-- gh-comment-id:161979689 -->
@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.)
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 @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.
@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.
@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.)
@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.0example?@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.
@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
Cvs12@hakanai commented on GitHub (Dec 4, 2015):
Well
Cis right out now, isn't it.@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.
@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.)