version number evolution discussions from Lyon 2014

version-pm-evolution.txt

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"

@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. version->new(v1.2.3_0) won't preserve the underscore, just like version->new(1.02_03) doesn't.

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.

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.

Add a title of something like "# The Lyon Compromise on Perl Module Version Handling" might help. I noted a long time ago that searchability for this was low. I'm dealing with another problem related to this in briandfoy/cpan-mini-inject#11 (likely similar to #110882).