Last active
January 4, 2016 19:25
-
-
Save dagolden/9559280 to your computer and use it in GitHub Desktop.
version number evolution discussions from Lyon 2014
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Broad decisions about rationalizing version object behavior based on | |
discussions at the Lyon QAH. Participants: David Golden, Ricardo Signes, | |
Karen Etheridge, Leon Timmermans, Peter Rabbitson and Graham Knop | |
- version comparision should be done irrespective of the presence of | |
underscores in the string used to initialize the version object | |
- underscore should no longer be used as a tuple separator in vstrings or | |
vstring-like strings; vstrings are converted to tuples by splitting into | |
*characters* (not bytes) and converting to codepoints; any elements after | |
the first must be in the range 0-999 | |
- numify/normal should produce a standarized string representation without | |
underscores | |
- stringify should produce the best possible representation of the value | |
used to initialize the version object; it should include underscores | |
only if the initializing value was a non-vstring string. | |
- floating point numbers used as initializers are converted to a decimal | |
string form at the precision limit of the architecture; people will be | |
warned about this in the documentation | |
Examples: | |
Comparison: | |
- version->new(1.0203) == version->new("1.0203") | |
- version->new(1.02_03) == version->new("1.02_03") | |
- version->new(v1.2.3) == version->new("v1.2.3") | |
- version->new(v1.2.3_0) == version->new("v1.2.3_0") | |
Underscore no longer tuple separator: | |
- version->new(v1.2.3_0) -> tuple (1,2,30) | |
- version->new("v1.2.3_0") -> tuple (1,2,30) | |
Numify/normalize don't produce underscore: | |
- version->new("1.0203")->numify -> "1.0203" | |
- version->new("1.0203")->normal -> "v1.20.300" | |
- version->new("1.02_03")->numify -> "1.0203" | |
- version->new("1.02_03")->normal -> "v1.20.300" | |
- version->new("v1.2.30")->numify -> "1.002030" | |
- version->new("v1.2.30")->normal -> "v1.2.30" | |
- version->new("v1.2.3_0")->numify -> "1.002030" | |
- version->new("v1.2.3_0")->normal -> "v1.2.30" | |
Stringify should attempt to preserve string initializers: | |
- version->new("1.0203")->stringify -> "1.0203" | |
- version->new("1.02_03")->stringify -> "1.02_03" | |
- version->new("v1.2.30")->stringify -> "v1.2.30" | |
- version->new("v1.2.3_0")->stringify -> "v1.2.3_0" | |
- version->new(1.0203)->stringify -> "1.0203" | |
- version->new(1.02_03)->stringify -> "1.0203" | |
- version->new(v1.2.30)->stringify -> "v1.2.30" | |
- version->new(v1.2.3_0)->stringify -> "v1.2.30" |
stringify should produce the best possible representation of the value used to initialize the version object; it should include underscores only if the initializing value was a non-vstring string.
This is confusing Module::Build, because it no longer recognizes 'v1.2.3_1'
as a testing version. See #110882. I have no idea if anyone is actually depending on this, but it does break at least one test. @xdg: opinion?
My understanding is that 'v1.2.3_1'
will still be seen as alpha, but v1.2.3_1
will not. The quoting being the important distinction.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The proposed patch has been integrated into 0.9912_01 and thence to 0.9913 except for the limitation "any elements after the first must be in the range 0-999". For one thing, for dotted decimal versions (either quoted or bare v-string), any leading zeros are not significant and will just be ignored when parsing (so 1.2.0000003 => v1.2.3). The other thing is that the current code does not enforce the 3 digit limit for subsequent elements. That can be considered a TODO for now.