Bug #89932 for CPAN-Changes: Version parsing so lax it basically accepts anything

Thu Oct 31 15:54:45 2013 KENTNL [...] cpan.org - Ticket created

Subject:

Version parsing so lax it basically accepts anything

A according to the spec, the only valid values for version are legal $versions.

However, the implementation is much more lax in this regard, and essentially permit arbitrary strings to be considered valid versions, as long as it is preceeded by a decimal, and it parses and renormalises this as-is without complaint.

Some people ( e.g.: Moose https://metacpan.org/changes/release/ETHER/Moose-2.1105-TRIAL#L4 ) have been using this notation, for reasons I believe are basically they expected it would work, and they tried it and it worked, and thus assumed it was somehow supported.

And as the attached test demonstrates, practically any characters are valid, and get parsed as versions:

So this seems like the following things are needed:

1. The Spec needs to be clarified what is, and what isn't legal in this regard, the spec says "Just match $version::LAX" , but this *much* more lax than that.

2. The code itself should either error or warn upon parsing unsupported version data like this. ( at least, for some of these example usecases )

3. Normalized output should be spec conforming "somehow", maybe with ->serialize() defaulting to strict behaviour and additional parameters required to make serialize emit non-spec-conformant data.

Some people are interested in having -TRIAL as being a supported part of versions, but until the spec says that is legal, they will not implement it as such

Subject:

changes.pl

#!/usr/bin/env perl use strict; use warnings; use utf8; use open ':std', OUT => ':utf8'; use CPAN::Changes; my $changes = CPAN::Changes->load_string(<<"EOF"); 0.1-TRIAL 2013-08-01 - test 0.10-TRIAL 2013-08-01 - test 0.001-TRIAL 2013-08-01 - test 0.ABCDEDF 2013-08-01 - test 0.â.â^ 2013-08-01 - test 1â 2013-08-01 - test EOF use Data::Dump qw(pp); for my $release ( $changes->releases ) { pp $release; } print $changes->serialize;

Thu Oct 31 15:56:17 2013 KENTNL [...] cpan.org - Correspondence added

Lol, looks like RT is no good at UTF8 encoding, make sure you download that script instead of copy-pasting it unless you want mojibake output =)

Thu Oct 31 16:01:07 2013 ether [...] cpan.org - Correspondence added

On 2013-10-31 12:54:45, KENTNL wrote: Show quoted text

> A according to the spec, the only valid values for version are legal > $versions. > > However, the implementation is much more lax in this regard, and > essentially > permit arbitrary strings to be considered valid versions, as long as > it is > preceeded by a decimal, and it parses and renormalises this as-is > without > complaint.

See also http://www.dagolden.com/index.php/2191/real-versions-on-cpan/ for other real-world examples you might want to use in testing. But really, all you should have to do is run the string through version::is_lax.

Thu Oct 31 16:01:08 2013 The RT System itself - Status changed from 'new' to 'open'

Thu Oct 31 16:01:21 2013 ether [...] cpan.org - Cc ETHER added

Sat May 23 02:52:03 2015 haarg [...] haarg.org - Correspondence added

To be specific, the parser will accept anything that starts with $version::LAX. Additionally, support for -TRIAL in parts of the API was explicitly added. To some extent, this is a compromise between strictness and usefulness. I'd like to separate the spec from the parser, because while I think it's useful to have the spec as a recommendation, the module itself isn't much use unless it can handle data that exists in the wild. So how loose do we think the parser should be? Things with -TRIAL or ->RC0 etc on the end are going to be difficult to fully specify.