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" |
This comment has been minimized.
This comment has been minimized.
we also talked about deprecating is_alpha |
This comment has been minimized.
This comment has been minimized.
Just want to throw a couple of comments attached to the above:
|
This comment has been minimized.
This comment has been minimized.
As an aside - what the above doesn't seem to cover for me is the sanity of keeping the ->normal semantic broken (i.e. s/_/./). I did not see a case where breaking the normal() behavior will result in any extra breakage on top of everything else. |
This comment has been minimized.
This comment has been minimized.
@ribasushi, I think github markdown ate some of your comments, but my reactions nonetheless:
|
This comment has been minimized.
This comment has been minimized.
To summarize the outcome of the discussion: we need to say in the docs something to the effect of "->normal should not be used by anyone besides packagers, and packagers should not be using anything other than version->new($ver)->normal" Thanks @dagolden for clarifying stuff, @ribasushi is reasonably happy. |
This comment has been minimized.
This comment has been minimized.
I do not remember the rationale behind this, and it doesn't make sense to me right now. Why did we want to threat vstrings special? It makes more sense to me to have the closest to the original representation. |
This comment has been minimized.
This comment has been minimized.
I'm pretty sure the rationale is to remove the reliance on v-string magic, so it could hopefully be removed in the future. v-strings already ignore underscores for their string component. I suspect @dagolden may be able to confirm that. |
This comment has been minimized.
This comment has been minimized.
@Leont also I believe that sentence is badly worded. It's trying to distinguish between quoted strings and v-string literals. We want to preserve underscores in all forms of quoted strings, but not in v-string literals, as the examples show. This isn't making vstrings special, but putting them on equal ground with numeric forms. |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
This is confusing Module::Build, because it no longer recognizes |
This comment has been minimized.
This comment has been minimized.
My understanding is that |
This comment has been minimized.
Another other thing I wonder about is whether "numify" should have a
minimum decimal length (e.g. padding with zeros on the right when
necessary).