use/package with "numeric literal" VERSIONs

[p5pRT]

Migrated from rt.perl.org#70866 (status was 'resolved')

Searchable as RT70866$

[p5pRT]

From frank.wiegand@gmail.com

This is a bug report for perl from frank.wiegand@​gmail.com\, generated with the help of perlbug 1.39 running under perl 5.11.2.

---

This topic has already been partially mentioned\, see http​://www.nntp.perl.org/group/perl.perl5.porters/2009/10/msg151830.html

perldoc5.11.2 -f package about »package NAME VERSION« syntax​:   »VERSION must be be a numeric literal or v-string».

perldoc5.11.2 -f use​:   »VERSION may be either a numeric argument such as 5.006\, which   will be compared to $]\, or a literal of the form v5.6.1«

perldoc5.11.2 about these I\​:

  Numeric literals are specified in any of the following floating   point or integer formats​:   12345   12345.67   .23E-10 # a very small number   3.14_15_92 # a very important number   4_294_967_296 # underscore for legibility   0xff # hex   0xdead_beef # more hex   0377 # octal (only numbers\, begins with 0)   0b011011 # binary

Those are all the things which pass C\<looks_like_number>\, so why is C\<looks_like_number> not used when perl parses C\ and C\ statements?

So I consider C\ and C\ are broken​:

  % cat Foo.pm   package Foo .1;   1;

  % perl5.11.2 -c Foo.pm   syntax error at Foo.pm line 1\, near "package Foo .1"   Foo.pm had compilation errors.

  % cat Foo2.pm   package Foo2;   our $VERSION = 1;   1;

  % perl5.11.2 -e 'use Foo2 10'   Foo2 version 10 required--this is only version 1 at -e line 2.   BEGIN failed--compilation aborted at -e line 2.  
  % perl5.11.2 -e 'use Foo2 1e1' # same as above but no failure

The last one parses wrong​:

  % perl5.11.2 -MO=Deparse -e 'use Foo2 1e1'   use Foo2 (10);   -e syntax OK

Thanks\, Frank

---

---

Flags​:   category=core   severity=low

---

Site configuration information for perl 5.11.2​:

Configured by fw at Fri Nov 20 12​:50​:33 CET 2009.

Summary of my perl5 (revision 5 version 11 subversion 2) configuration​:  
  Platform​:   osname=linux\, osvers=2.6.30-2-amd64\, archname=x86_64-linux   uname='linux hal2 2.6.30-2-amd64 #1 smp fri sep 25 22​:16​:56 utc 2009 x86_64 gnulinux '   config_args='-de -Dusedevel -Dprefix=/opt/perl/perl-5.11.2'   hint=recommended\, useposix=true\, d_sigaction=define   useithreads=undef\, usemultiplicity=undef   useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef   use64bitint=define\, use64bitall=define\, uselongdouble=undef   usemymalloc=n\, bincompat5005=undef   Compiler​:   cc='cc'\, ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\,   optimize='-O2'\,   cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'   ccversion=''\, gccversion='4.3.4'\, gccosandvers=''   intsize=4\, longsize=8\, ptrsize=8\, doublesize=8\, byteorder=12345678   d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16   ivtype='long'\, ivsize=8\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8   alignbytes=8\, prototype=define   Linker and Libraries​:   ld='cc'\, ldflags =' -fstack-protector -L/usr/local/lib'   libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64   libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc   perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc   libc=/lib/libc-2.10.1.so\, so=so\, useshrplib=false\, libperl=libperl.a   gnulibc_version='2.10.1'   Dynamic Linking​:   dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E'   cccdlflags='-fPIC'\, lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector'

Locally applied patches​:  

---

@​INC for perl 5.11.2​:   /opt/perl/perl-5.11.2/lib/site_perl/5.11.2/x86_64-linux   /opt/perl/perl-5.11.2/lib/site_perl/5.11.2   /opt/perl/perl-5.11.2/lib/5.11.2/x86_64-linux   /opt/perl/perl-5.11.2/lib/5.11.2   .

---

Environment for perl 5.11.2​:   HOME=/home/fw   LANG=de_DE.UTF-8   LANGUAGE=   LD_LIBRARY_PATH (unset)   LOGDIR (unset)   PATH=/sbin​:/usr/sbin​:/home/fw/bin​:/home/fw/bin​:/usr/local/bin​:/usr/bin​:/bin​:/usr/games   PERL_AUTOINSTALL=--defaultdeps   PERL_BADLANG (unset)   PERL_EXTUTILS_AUTOINSTALL=--defaultdeps   PERL_MM_USE_DEFAULT=1   SHELL=/bin/zsh

[p5pRT]

From @xdg

Having thought long and hard about the insanity of module version numbers in Perl [1]\, I'd much rather see the rules tightened rather than loosened.

I agree that the current docs do not describe reality well\, but I'd much rather see the documentation amended than to loosen what is allowed to looks_like_number.

I'd rather go even further and really restrict allowable version number forms\, but I haven't the energy and tuits to roll that rock uphill against "breaks backwards compatibility" naysayers.

But if I had my way\, there would be only two allowed forms​:

(1) decimal​: limited to positive decimal numbers matching qr/\d+(?​:\.\d+)?/

(2) dotted-integer​: only with a leading v and at least three components\, with no component other than the first greater than 999; matching qr/v\d+(?​:\.\d\d?\d?){2}(?​:\.\d\d?\d?)*/

My regexes are probably buggy given the hour\, but hopefully people get the idea. I'd like to remove any possible ambiguity between forms. I'd like to see "alpha" underscores go away. I hate how much time I've spent dealing with version number issues while working on the Perl toolchain.

-- David

[1] http​://www.dagolden.com/index.php/369/version-numbers-should-be-boring/

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @andk

On Fri\, 27 Nov 2009 20​:26​:54 -0800\, "David Golden via RT" \perlbug\-followup@&#8203;perl\.org said​:

  > I'd rather go even further and really restrict allowable version number   > forms\, but I haven't the energy and tuits to roll that rock uphill   > against "breaks backwards compatibility" naysayers.

Since the syntax 'package Package Version;' is a new syntax we are absolutely free to design this one right from scratch\, no?

It reminds me of Larry's choice of C\< (? > in regular expressions that opened a whole new world of possibilities without breaking backwards compatibility.

-- andreas

[p5pRT]

From @tsee

Hi\,

On Fri Nov 27 20​:26​:52 2009\, dagolden@​cpan.org wrote​:

Having thought long and hard about the insanity of module version numbers in Perl [1]\, I'd much rather see the rules tightened rather than loosened.

It seems hard to disagree with that.

I agree that the current docs do not describe reality well\, but I'd much rather see the documentation amended than to loosen what is allowed to looks_like_number.

I'd rather go even further and really restrict allowable version number forms\, but I haven't the energy and tuits to roll that rock uphill against "breaks backwards compatibility" naysayers.

I think this fear is addressed well by Andreas' comment​: You can't break backwards compatibility in new syntax (unless the syntax itself possibly breaks compatibility\, cf. class keyword). You can only break expectations. And I think that's precisely what you (and I and many others) *want* here.

But if I had my way\, there would be only two allowed forms​:

(1) decimal​: limited to positive decimal numbers matching qr/\d+(?​:\.\d+)?/

(2) dotted-integer​: only with a leading v and at least three components\, with no component other than the first greater than 999; matching qr/v\d+(?​:\.\d\d?\d?){2}(?​:\.\d\d?\d?)*/

My regexes are probably buggy given the hour\, but hopefully people get the idea. I'd like to remove any possible ambiguity between forms.

Those regexes seem fine to me.

I'd like to see "alpha" underscores go away. I hate how much time I've spent dealing with version number issues while working on the Perl toolchain.

At first\, I went *yuck*. Don't take away my tools to mark something as alpha. But then\, I realized that I want to mark distributions as alpha\, not packages/modules. So it doesn't apply unless I insist to only ever use the version from a .pm file in a distribution version. I don't.

IMHO\, a decision on the behaviour and subsequent documentation fixes should be considered a 5.12 showstopper or else we lose the window of opportunity to define new syntax with the sane behaviour.

Note that if we realize limiting the valid versions specifiers in the construct was a bad idea\, we can relax it later. Just not the other way around.

Cheers\, Steffen

[p5pRT]

From @obra

At first\, I went *yuck*.

Ditto\, but I've come around\, thanks mostly to well-reasoned explanations by several porters. I see the value in making the new syntax only accept version numbers of the two styles mentioned by David.

IMHO\, a decision on the behaviour and subsequent documentation fixes should be considered a 5.12 showstopper or else we lose the window of opportunity to define new syntax with the sane behaviour.

Let's do it. I've marked this ticket as a 5.12 showstopper. We can always loosen it up for 5.14.

-Jesse

[p5pRT]

From @JohnPeacock

jesse wrote​:

Ditto\, but I've come around\, thanks mostly to well-reasoned explanations by several porters. I see the value in making the new syntax only accept version numbers of the two styles mentioned by David.

I'm +1 on this as well\, and if there is anything that needs to get changed in the version code to make this easier\, I will make time to change it.

John

[p5pRT]

From zefram@fysh.org

David Golden wrote​:

But if I had my way\, there would be only two allowed forms​:

(1) decimal​: limited to positive decimal numbers matching qr/\d+(?​:\.\d+)?/

(2) dotted-integer​: only with a leading v and at least three components\, with no component other than the first greater than 999; matching qr/v\d+(?​:\.\d\d?\d?){2}(?​:\.\d\d?\d?)*/

We ought to put accurate regexps into the documentation\, both to directly document the syntax and for people to copy into toolchain modules. I think the regexps you actually want are

  qr/(?​:0|[1-9][0-9]*)(?​:\.[0-9]+)?/   qr/v(?​:0|[1-9][0-9]*)(?​:\.(?​:0|[1-9][0-9]{0\,2})){2\,}/

This rules out non-ASCII digits\, octal literals\, and v-string components that look like they might be octal (though they actually get interpreted as decimal anyway). Alternatively\, if you want to support v-string usage such as "v2010.02.28" (for dates)\, the latter restriction can be dropped\, leading to

  qr/v[0-9]+(?​:\.0*(?​:0|[1-9][0-9]{0\,2})){2\,}/

which would also allow "v2010.0002.0028"\, which you might not be intending. If you actually want a restriction on the *number of digits* in later v-string components\, rather than on the numerical value\, you get

  qr/v[0-9]+(?​:\.[0-9]{1\,3}){2\,}/

I hate v-strings.

Also\, when you add anchors to these regexps\, be sure to use /\A/ and /\z/\, not /^/ and /$/\, because we don't want newlines creeping into version numbers either.

-zefram

[p5pRT]

From frank.wiegand@gmail.com

Am Montag\, den 30.11.2009\, 18​:06 +0000 schrieb Zefram​:

We ought to put accurate regexps into the documentation\, both to directly document the syntax and for people to copy into toolchain modules.

That would be great. The hints for setting version numbers using a (new) »best practise« should be at least mentioned in `perldoc -f package' and perlmodstyle.pod\, IMHO.

I think the regexps you actually want are

qr/\(?​:0|\[1\-9\]\[0\-9\]\*\)\(?​:\\\.\[0\-9\]\+\)?/

[...] If you actually want a restriction on the *number of digits* in later v-string components\, rather than on the numerical value\, you get

qr/v\[0\-9\]\+\(?​:\\\.\[0\-9\]\{1\,3\}\)\{2\,\}/

Using these REs\, here are some ticket candidates from CPAN​:

  % cat bad-versions.pl   #!/usr/bin/perl -w  
  use 5.010;   use strict;  
  my $valid = qr/\A (?​: (?​:0|[1-9][0-9]*)(?​:\.[0-9]+)? ) | (?​: v[0-9]+(?​:\.[0-9]{1\,3}){2\,} ) \z/x;  
  while(\<>) {   chomp;   my ($module\, $version\, $dist) = split;   next if $version eq 'undef';   say if $version !~ /$valid/;   }   __END__  
  % zcat 02packages.details.txt.gz | tail -n+10 - | perl bad-versions.pl   Apache​::mod_pml VERSION P/PJ/PJONES/PML-0.4.1.tar.gz
  Array​::Parallel .01 W/WI/WILL/Array-Sort-0.02.tar.gz
  Array​::Suffix .5 B/BT/BTMCINNES/Array-Suffix-0.5.tar.gz
  Business​::Payroll​::US​::FedIncome .3 J/JA/JAMESP/payroll/business-payroll-1.3.tar.gz
  Business​::Payroll​::US​::FICA .4 J/JA/JAMESP/payroll/business-payroll-1.3.tar.gz
  Business​::Payroll​::US​::Medicare .4 J/JA/JAMESP/payroll/business-payroll-1.3.tar.gz
  Business​::Payroll​::US​::Mileage .3 J/JA/JAMESP/payroll/business-payroll-1.3.tar.gz
  Database​::Schema​::Config .02 S/SA/SAXJAZMAN/database/Database-Schema-Config-.02.tar.gz   DBIx​::Class​::Fixtures​::SchemaVersioned set-when-loading L/LS/LSAUNDERS/DBIx-Class-Fixtures-1.001001.tar.gz   DBR unknown I/IM/IMPIOUS/DBR-1.0.7rc2.tar.gz
  Device​::Gsm​::Charset Revision C/CO/COSIMO/Device-Gsm-1.54.tar.gz
  EC​::About v36 R/RK/RKIES/ec-1.28.tar.gz
  EC​::PasswordDialog v36 R/RK/RKIES/ec-1.28.tar.gz   HTML​::Encapsulate v0.3 N/NP/NPW/HTML-Encapsulate-v0.3.tar.gz   IO​::Stty .02 A/AU/AUSCHUTZ/IO-Stty-.02.tar.gz   JListbox .01 D/DJ/DJBERG/Tk-JListbox-0.01.tar.gz   LWP​::UserAgent​::Snapshot v0.2 N/NP/NPW/LWP-UserAgent-Snapshot-v0.2.tar.gz   Mail​::SpamAssassin​::Conf bogus J/JM/JMASON/Mail-SpamAssassin-3.2.5.tar.gz   Mail​::SpamAssassin​::Dns bogus J/JM/JMASON/Mail-SpamAssassin-3.2.5.tar.gz   Mail​::SpamAssassin​::Plugin bogus F/FE/FELICITY/Mail-SpamAssassin-3.1.8.tar.gz   Mail​::SpamAssassin​::PluginHandler bogus F/FE/FELICITY/Mail-SpamAssassin-3.1.8.tar.gz   Mail​::SpamAssassin​::Reporter bogus J/JM/JMASON/Mail-SpamAssassin-3.2.5.tar.gz   Mail​::SPF v2.007 J/JM/JMEHNLE/mail-spf/Mail-SPF-v2.007.tar.gz   Math​::FractionDemo .53 K/KE/KEVINA/Fraction-v.53b.tar.gz   Maypole​::Model​::CDBI​::AsForm .97 T/TE/TEEJAY/Maypole-2.13.tar.gz   Net​::Download​::Queue​::Download Net J/JO/JOHANL/Net-Download-Queue-0.04.tar.gz   Net​::Download​::Queue​::DownloadStatus Net J/JO/JOHANL/Net-Download-Queue-0.04.tar.gz   Net​::Route v0.02 T/TE/TEQUETER/Net-Route-v0.02.tar.gz   PML​::Storable VERSION P/PJ/PJONES/PML-0.4.1.tar.gz   PPresenter v1.17 M/MA/MARKOV/PPresenter-1.17.tar.gz   SMS​::Handler​::Blackhole Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz   SMS​::Handler​::Dispatcher Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz   SMS​::Handler​::Email Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz   SMS​::Handler​::Invoke Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz   SMS​::Handler​::Ping Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz   SMS​::Handler​::Utils Revision L/LU/LUISMUNOZ/SMS-Handler-0.01.tar.gz   Tk​::JListbox .01 D/DJ/DJBERG/Tk-JListbox-0.02.tar.gz   Tk​::SearchDialog v36 R/RK/RKIES/Tk-Workspace-1.75.tar.gz   Tk​::Shell v36 R/RK/RKIES/Tk-Workspace-1.75.tar.gz

Note​: These might not be the real version data\, but it is what the PAUSE indexer creates and therefore CPAN.pm uses.

It's not as much as I thought.

Frank

[p5pRT]

From @xdg

I'll summarize a conversation from IRC today.

In part\, my "wishlist" is to harmonize how $VERSION is defined\, how $VERSION is statically parsed by EU​::MM->parse_version and Module​::Build​::ModuleInfo\, how $VERSION is specified to use()\, what gets returned by UNIVERSAL​::VERSION and what version->new($version) gives.

I'd like to be able to "round-trip" a version any which way

* set it via package NAME VERSION * statically parse it and get the same thing back * eval "use Foo $version" and succeed * get the same thing back from Foo->VERSION * give it to version->new() and get back the same thing.

I have posted some sample code that shows cases that work and that fail.

http​://gist.github.com/245765

-- David

[p5pRT]

From @JohnPeacock

David Golden wrote​:

I'd like to be able to "round-trip" a version any which way

* set it via package NAME VERSION * statically parse it and get the same thing back * eval "use Foo $version" and succeed * get the same thing back from Foo->VERSION * give it to version->new() and get back the same thing.

I have posted some sample code that shows cases that work and that fail.

http​://gist.github.com/245765

I'll take a look at this tonight...

John

[p5pRT]

From @JohnPeacock

On 11/30/2009 04​:51 PM\, David Golden wrote​:

In part\, my "wishlist" is to harmonize how $VERSION is defined\, how $VERSION is statically parsed by EU​::MM->parse_version and Module​::Build​::ModuleInfo\, how $VERSION is specified to use()\, what gets returned by UNIVERSAL​::VERSION and what version->new($version) gives.

OK\, to start with the core Perl code uses a completely unique parser in S_force_version and friends\, different from the version.pm-derived code in util.c. This is part of the core that I didn't touch when I integrated version.pm and hence it doesn't follow the same rules as the version object code.

In particular\, it uses Perl_scan_num\, which will eat underscores without recourse. It also uses the old method of creating a dual-var (PV and NV forms) and uses SvNOK_on to "hint" that this is a version. This will work "most of the time"\, but those edge cases (especially surrounding v-strings) are precisely why I wrote version.pm in the first place.

If we want to have One True version parsing\, I'd think we would all prefer that we have one piece of code for both version.pm and use/package. I may actually have a patch to this code on my other box to unify both streams; I'll look in a minute.

But I wanted to point this out now\, before we go any further down this hole​: Module​::Build is using version.pm; I have an unapplied patch EU​::MM to use version.pm in the same way that Module​::Build does (embedded pure Perl or installed version.pm). I would certainly prefer to make S_force_version use the same parser as the version object code in the core\, so that we can guarantee that all roads lead to the same destination.

I'm willing to alter Perl_scan_version to\, for example\, ignore underscores in alpha versions if requested\, or refuse to scan them at all (if that is preferable). All we need is a consensus on what we want to allow and what we want to forbid.

John

[p5pRT]

From david@kineticode.com

On Nov 30\, 2009\, at 6​:58 PM\, John Peacock wrote​:

OK\, to start with the core Perl code uses a completely unique parser in S_force_version and friends\, different from the version.pm-derived code in util.c. This is part of the core that I didn't touch when I integrated version.pm and hence it doesn't follow the same rules as the version object code.

In particular\, it uses Perl_scan_num\, which will eat underscores without recourse. It also uses the old method of creating a dual-var (PV and NV forms) and uses SvNOK_on to "hint" that this is a version. This will work "most of the time"\, but those edge cases (especially surrounding v-strings) are precisely why I wrote version.pm in the first place.

If we want to have One True version parsing\, I'd think we would all prefer that we have one piece of code for both version.pm and use/package. I may actually have a patch to this code on my other box to unify both streams; I'll look in a minute.

But I wanted to point this out now\, before we go any further down this hole​: Module​::Build is using version.pm; I have an unapplied patch EU​::MM to use version.pm in the same way that Module​::Build does (embedded pure Perl or installed version.pm). I would certainly prefer to make S_force_version use the same parser as the version object code in the core\, so that we can guarantee that all roads lead to the same destination.

I'm willing to alter Perl_scan_version to\, for example\, ignore underscores in alpha versions if requested\, or refuse to scan them at all (if that is preferable). All we need is a consensus on what we want to allow and what we want to forbid.

Wouldn't that potentially break some existing modules that use package variables to declare version numbers?

It seems to me that version.pm and `package NAME VERSION` should use the same parser\, with rules as specced out by David Golden\, but perhaps the old parser should be left for the poor souls still using the package variable declaration form (or whatever context it is that's not using version.pm's parser)?

Best\,

David

[p5pRT]

From @JohnPeacock

On 11/30/2009 10​:08 PM\, David E. Wheeler wrote​:

On Nov 30\, 2009\, at 6​:58 PM\, John Peacock wrote​:

I'm willing to alter Perl_scan_version to\, for example\, ignore underscores in alpha versions if requested\, or refuse to scan them at all (if that is preferable). All we need is a consensus on what we want to allow and what we want to forbid.

Wouldn't that potentially break some existing modules that use package variables to declare version numbers?

The altered behavior would only happen if a flag was set; the default behavior would be unchanged from what it is now. Anyone using

  use version; our $VERSION = version->new("1.2.3");

would continue to get exactly what they asked for...

It seems to me that version.pm and `package NAME VERSION` should use the same parser\, with rules as specced out by David Golden\, but perhaps the old parser should be left for the poor souls still using the package variable declaration form (or whatever context it is that's not using version.pm's parser)?

The old parser that I am talking about is only used for​:

  use package 1.1;

and now

  package foo 1.2;

Nothing else uses that codepath at all. What I am suggesting is that I make Perl_scan_version enforce the rules that David Golden (and others) have suggested and only use those limitations when called internally by those two instances listed above.

John

[p5pRT]

From david@kineticode.com

On Nov 30\, 2009\, at 7​:24 PM\, John Peacock wrote​:

The altered behavior would only happen if a flag was set; the default behavior would be unchanged from what it is now. Anyone using

use version; our $VERSION = version\->new\("1\.2\.3"\);

would continue to get exactly what they asked for...

As would folks just doing

  our $VERSION = '1.2.3';

or

  use vars '$VERSION';   $VERSION = 1.2;

?

The old parser that I am talking about is only used for​:

use package 1\.1;

and now

package foo 1\.2;

Nothing else uses that codepath at all. What I am suggesting is that I make Perl_scan_version enforce the rules that David Golden (and others) have suggested and only use those limitations when called internally by those two instances listed above.

+1.

Best\,

David

[p5pRT]

From @JohnPeacock

On 11/30/2009 10​:30 PM\, David E. Wheeler wrote​:

As would folks just doing

 our $VERSION = '1\.2\.3';

or

 use vars '$VERSION';
 $VERSION = 1\.2;

?

Correct. The only time that force_version is called is when the only token that can be next is a version (cf use/package). Those are just assignments to a certain scalar; the only time that the version object code gets called in that case is when UNIVERSAL​::VERSION gets called (either directly as foo->VERSION or indirectly by 'use foo 1.2'). And even then\, the original $VERSION scalar is never itself upgraded; that was felt to be too magical (though I had a way to do it of course)...

John

[p5pRT]

From david@kineticode.com

On Nov 30\, 2009\, at 7​:38 PM\, John Peacock wrote​:

Correct. The only time that force_version is called is when the only token that can be next is a version (cf use/package). Those are just assignments to a certain scalar; the only time that the version object code gets called in that case is when UNIVERSAL​::VERSION gets called (either directly as foo->VERSION or indirectly by 'use foo 1.2'). And even then\, the original $VERSION scalar is never itself upgraded; that was felt to be too magical (though I had a way to do it of course)...

Sound good to me!

Best\,

David

[p5pRT]

From @xdg

On Mon\, Nov 30\, 2009 at 10​:08 PM\, David E. Wheeler \david@&#8203;kineticode\.com wrote​:

On Nov 30\, 2009\, at 6​:58 PM\, John Peacock wrote​:

I'm willing to alter Perl_scan_version to\, for example\, ignore underscores in alpha versions if requested\, or refuse to scan them at all (if that is preferable).  All we need is a consensus on what we want to allow and what we want to forbid.

Wouldn't that potentially break some existing modules that use package variables to declare version numbers?

Yes.

It seems to me that version.pm and `package NAME VERSION` should use the same parser\, with rules as specced out by David Golden\, but perhaps the old parser should be left for the poor souls still using the package variable declaration form (or whatever context it is that's not using version.pm's parser)?

I think the current rough "consensus" on IRC is as follows​:

* For Version 12\, have "package NAME VERSION" be strict and "use NAME VERSION" (and by extension UNIVERSAL​::VERSION) be liberal. Thus\, nothing old breaks\, but nothing using the new 'package NAME VERSION" syntax will break in the future when use()/VERSION() become stricter.

* For Version 14\, use NAME VERSION (and UNIVERSAL​::VERSION) should be liberal\, but issue deprecation warnings for "bad" version numbers

* For Version 16\, use() and VERSION() are strict in what they accept and die with a syntax error otherwise

This means 'package NAME VERSION' needs to be stricter than it is now before Version 12 is released. I don't think use() needs to be fixed to accept things it currently doesn't (like '.01') but it should be documented more clearly as to what it accepts.

-- David

[p5pRT]

From chromatic@wgz.org

On Monday 30 November 2009 at 10​:06\, Zefram wrote​:

We ought to put accurate regexps into the documentation\, both to directly document the syntax and for people to copy into toolchain modules.

+1 to giving regexps which document the syntax\, but minus several to encouraging people to copy and paste them. Here's a nice chance to reduce fragmentation of syntax; let's reduce fragmentation of implementation as well.

-- c

[p5pRT]

From @JohnPeacock

On 11/30/2009 10​:50 PM\, David Golden wrote​:

* For Version 12\, have "package NAME VERSION" be strict and "use NAME VERSION" (and by extension UNIVERSAL​::VERSION) be liberal. Thus\, nothing old breaks\, but nothing using the new 'package NAME VERSION" syntax will break in the future when use()/VERSION() become stricter.

Can do this using what I discussed already elsewhere.

* For Version 14\, use NAME VERSION (and UNIVERSAL​::VERSION) should be liberal\, but issue deprecation warnings for "bad" version numbers

and also version.pm\, since someone using version.pm for \< 14 needs to get the same warnings as the code will get with 14+.

* For Version 16\, use() and VERSION() are strict in what they accept and die with a syntax error otherwise

ditto for version.pm for the same reasons.

This means 'package NAME VERSION' needs to be stricter than it is now before Version 12 is released. I don't think use() needs to be fixed to accept things it currently doesn't (like '.01') but it should be documented more clearly as to what it accepts.

I'm sure that use() will get fixed to be consistent about what it accepts simply by switching to the scan_version parser (in non-strict mode).

I'll start sketching this out tomorrow night...

John

[p5pRT]

From @xdg

On Mon\, Nov 30\, 2009 at 11​:01 PM\, John Peacock \john\.peacock@&#8203;havurah\-software\.org wrote​:

I'll start sketching this out tomorrow night...

Please coordinate with Zefram and Steffen\, as they have already been working on this a bit and I'd hate to see the three of you duplicating effort or taking things in diverging directions.

-- David

[p5pRT]

From @ap

* chromatic \chromatic@&#8203;wgz\.org [2009-12-01 05​:00]​:

+1 to giving regexps which document the syntax\, but minus several to encouraging people to copy and paste them. Here's a nice chance to reduce fragmentation of syntax; let's reduce fragmentation of implementation as well.

So what do you propose instead? Exposing the scan_version routine to pure Perl code somehow?

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

[p5pRT]

From chromatic@wgz.org

On Monday 30 November 2009 at 20​:45\, Aristotle Pagaltzis wrote​:

* chromatic \chromatic@&#8203;wgz\.org [2009-12-01 05​:00]​:

+1 to giving regexps which document the syntax\, but minus several to encouraging people to copy and paste them. Here's a nice chance to reduce fragmentation of syntax; let's reduce fragmentation of implementation as well.

So what do you propose instead? Exposing the scan_version routine to pure Perl code somehow?

If the intent is to migrate to a single\, consistent form for version numbers by 5.16\, perhaps the best approach is to expose that routine somewhere like version.pm.

Pros​: it's a core module\, it will remain a core module\, and it already handles version numbers.

Con​: that feature won't be available when installing the CPAN version.pm on older Perls. Then again\, neither is the package VERSION syntax.

-- c

[p5pRT]

From ben@morrow.me.uk

Quoth xdaveg@​gmail.com (David Golden)​:

* For Version 12\, have "package NAME VERSION" be strict and "use NAME

Since this is a discussion about version number confusion​: are we *really* going to start referring to 5.12 as 'Version 12'? The potential for confusion is enormous.

Ben

[p5pRT]

From ben@morrow.me.uk

Quoth chromatic@​wgz.org (Chromatic)​:

If the intent is to migrate to a single\, consistent form for version numbers by 5.16\, perhaps the best approach is to expose that routine somewhere like version.pm.

Pros​: it's a core module\, it will remain a core module\, and it already handles version numbers.

Con​: that feature won't be available when installing the CPAN version.pm on older Perls. Then again\, neither is the package VERSION syntax.

Why not? What you're talking about is just a parsing routine\, so the CPAN version of version could perfectly well provide a version compatible with what 5.16 does in core.

Ben

[p5pRT]

From @xdg

On Tue\, Dec 1\, 2009 at 12​:08 AM\, chromatic \chromatic@&#8203;wgz\.org wrote​:

If the intent is to migrate to a single\, consistent form for version numbers by 5.16\, perhaps the best approach is to expose that routine somewhere like version.pm.

To that end\, we would probably want EU​::MM->parse_version\, M​::B​::ModuleInfo\, and UNIVERSAL​::VERSION to return version objects and start teaching people to only use Foo->VERSION\, and never $Foo​::VERSION to retrieve VERSION during runtime.

If we really want to lock things down\, $VERSION needs to become a reserved global. At the least\, it should be readonly and set to 0 by "package NAME;". Even stricter\, attempting to read $VERSION directly would be a syntax error (after a sufficient deprecation warning cycle).

-- David

[p5pRT]

From @xdg

On Tue\, Dec 1\, 2009 at 2​:08 AM\, Ben Morrow \ben@&#8203;morrow\.me\.uk wrote​:

Quoth xdaveg@​gmail.com (David Golden)​:

* For Version 12\, have "package NAME VERSION" be strict and "use NAME

Since this is a discussion about version number confusion​: are we *really* going to start referring to 5.12 as 'Version 12'? The potential for confusion is enormous.

Excerpt from "perl -V"​:

  Summary of my perl5 (revision 5 version 11 subversion 2) configuration​:

It's been "Version 6"\, "Version 8"\, "Version 10" ... this is *old* not *new*. It's only new (and thus strange) to start referring to it properly.

-- David

[p5pRT]

From @abigail

On Mon\, Nov 30\, 2009 at 04​:51​:41PM -0500\, David Golden wrote​:

I'll summarize a conversation from IRC today.

In part\, my "wishlist" is to harmonize how $VERSION is defined\, how $VERSION is statically parsed by EU​::MM->parse_version and Module​::Build​::ModuleInfo\, how $VERSION is specified to use()\, what gets returned by UNIVERSAL​::VERSION and what version->new($version) gives.

I'd like to be able to "round-trip" a version any which way

* set it via package NAME VERSION * statically parse it and get the same thing back * eval "use Foo $version" and succeed * get the same thing back from Foo->VERSION * give it to version->new() and get back the same thing.

I have posted some sample code that shows cases that work and that fail.

As long as $VERSION is allowed to match /^[0-9]{10}$/\, I'm happy.

I've given up using dots in any Perl related version numbers long time ago.

Abigail

[p5pRT]

From @xdg

On Tue\, Dec 1\, 2009 at 5​:24 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

As long as $VERSION is allowed to match /^[0-9]{10}$/\, I'm happy.

Do you *really* want leading 0 (i.e. octal) version numbers? :-)

-- David

[p5pRT]

From zefram@fysh.org

Abigail wrote​:

As long as $VERSION is allowed to match /^[0-9]{10}$/\, I'm happy.

What\, like

  our $VERSION = "0000000100\n";

?

-zefram

[p5pRT]

From @abigail

On Tue\, Dec 01\, 2009 at 10​:34​:56AM +0000\, Zefram wrote​:

Abigail wrote​:

As long as $VERSION is allowed to match /^[0-9]{10}$/\, I'm happy.

What\, like

our $VERSION = "0000000100\\n";

No\, but $VERSION = "0000010101" may happen\, for the first release I do on Jan 1\, 10000 (see my replay to David).

Abigail

[p5pRT]

From @nwc10

On Tue\, Dec 01\, 2009 at 05​:21​:53AM -0500\, David Golden wrote​:

On Tue\, Dec 1\, 2009 at 2​:08 AM\, Ben Morrow \ben@&#8203;morrow\.me\.uk wrote​:

Quoth xdaveg@​gmail.com (David Golden)​:

* For Version 12\, have "package NAME VERSION" be strict and "use NAME

Since this is a discussion about version number confusion​: are we *really* going to start referring to 5.12 as 'Version 12'? The potential for confusion is enormous.

Excerpt from "perl -V"​:

Summary of my perl5 (revision 5 version 11 subversion 2) configuration​:

It's been "Version 6"\, "Version 8"\, "Version 10" ... this is *old* not *new*. It's only new (and thus strange) to start referring to it properly.

But *that* is in the context of "5 version $x subversion $y" and it's lowercase. You're deliberately using Titlecase here\, which makes some sense as I believe you're trying to make it clear that it's a "special" word.

However I still don't like the use of /version/i anywhere "loose" like this\, as the temptation to then shorten it to v12 is too great. and then v12.0 (and v12.1)\, which\, well​:

$ ./perl -e 'require v11' Perl v11.0.0 required--this is only v5.11.2\, stopped at -e line 1. $ ./perl -e 'require v11.0' Perl v11.0.0 required--this is only v5.11.2\, stopped at -e line 1.

and\, best of all\, the documented fun once we get to maint releases​:

$ ./perl -lwe 'print version->new(12.0) cmp v12.0' 0 $ ./perl -lwe 'print version->new(12.1) cmp v12.1' 1

For a marketing-compatible string\, I preferred the word "release"\, as in

  "Perl 5 release 12"

and then

  "Perl 5 release 12 update 1"

(etc)

as​:

1​: it avoids the massively overloaded v-word. 0​: There is no .0 release :-)

Nicholas Clark

[p5pRT]

From @obra

On Mon 30.Nov'09 at 22​:50​:45 -0500\, David Golden wrote​:

I think the current rough "consensus" on IRC is as follows​:

* For Version 12\, have "package NAME VERSION" be strict and "use NAME VERSION" (and by extension UNIVERSAL​::VERSION) be liberal.

Agreed.

Thus\, nothing old breaks\, but nothing using the new 'package NAME VERSION" syntax will break in the future when use()/VERSION() become stricter.

* For Version 14\, use NAME VERSION (and UNIVERSAL​::VERSION) should be liberal\, but issue deprecation warnings for "bad" version numbers

I haven't actually agreed to the deprecation of "use NAME TRADITIONAL_INSANE_VERSION" yet. I have a sneaking suspicion that this is going to be less straightforward than one might hope and don't really want to needlessly break users' code. Don't get me wrong -- It's definitely worth exploring what would happen if this change were made. I'd love to see versioning get saner\, but I'd like to proceed with extreme caution.

* For Version 16\, use() and VERSION() are strict in what they accept and die with a syntax error otherwise

^ See above

This means 'package NAME VERSION' needs to be stricter than it is now before Version 12 is released. I don't think use() needs to be fixed to accept things it currently doesn't (like '.01') but it should be documented more clearly as to what it accepts.

+1

[p5pRT]

From @obra

* For Version 14\, use NAME VERSION (and UNIVERSAL​::VERSION) should be liberal\, but issue deprecation warnings for "bad" version numbers

and also version.pm\, since someone using version.pm for \< 14 needs to get the same warnings as the code will get with 14+.

That suggests that upgrading to a newer version.pm will cause code that used to work right to start complaining (or eventually dying if I read your comments about 16 correctly). That seems counterproductive.

-Jesse

[p5pRT]

From @xdg

On Tue\, Dec 1\, 2009 at 9​:10 AM\, Jesse Vincent \jesse@&#8203;bestpractical\.com wrote​:

* For Version 14\, use NAME VERSION (and UNIVERSAL​::VERSION) should be liberal\, but issue deprecation warnings for "bad" version numbers

and also version.pm\, since someone using version.pm for \< 14 needs to get the same warnings as the code will get with 14+.

That suggests that upgrading to a newer version.pm will cause code that used to work right to start complaining (or eventually dying if I read your comments about 16 correctly).   That seems counterproductive.

I think I agree with Jesse on this one. version.pm needs to conform to the Perl version that it is running under rather than try to backport version semantics to older Perls (any more than it already is).

So version.pm should only issue deprecations warnings as of Perl 5 [ahem] *release* 14 if we indeed decide to do that. [Happy\, Nicholas?]

-- David

[p5pRT]

From @JohnPeacock

On 12/01/2009 11​:33 AM\, David Golden wrote​:

I think I agree with Jesse on this one. version.pm needs to conform to the Perl version that it is running under rather than try to backport version semantics to older Perls (any more than it already is).

There are two competing forces here​:

1) You upgrade Perl and your script breaks 2) You upgrade version.pm and your script breaks

I think we can all agree that #2 will happen more often. At least in my mind\, #1 is more important (and yet easier to fix because you will expect some period of adjustment). Did you see the listing that Frank Wiegand posted of modules on CPAN that would run afoul of the New World Version Order? I know that CPAN != the Universe of Perl Scripts\, but that is a remarkably short list of modules that need to be fixed.

Even in our wildest dreams\, I would think that two years between 5.12.0 and 5.14.0; plenty of time to fix up modules that warn before they will die instead.

So version.pm should only issue deprecations warnings as of Perl 5 [ahem] *release* 14 if we indeed decide to do that. [Happy\, Nicholas?]

version.pm doesn't actually "run" on the Perl's where it is in the core (5.10.0 and beyond). The CPAN release of version.pm is there only to provide the same version object behavior to earlier Perl's. As such\, I think that it would be much saner that version.pm works the same\, whether it is in core or not. Having it behave differently\, depending on which release of Perl you are running it on is\, in fact\, completely counter to the reason I wrote it in the first place. It shouldn't matter what release of Perl you are running; version.pm should behave identically...

John

[p5pRT]

From @xdg

On Tue\, Dec 1\, 2009 at 7​:12 PM\, John Peacock \john\.peacock@&#8203;havurah\-software\.org wrote​:

Having it behave differently\, depending on which release of Perl you are running it on is\, in fact\, completely counter to the reason I wrote it in the first place.  It shouldn't matter what release of Perl you are running; version.pm should behave identically...

John\,

With all due respect\,\, that's what I disagree with. In hindsight\, I think that version.pm should have been strictly limited to providing an interface to the Perl internals for version number conversion and comparison.

Having externally available version objects\, changing UNIVERSAL​::VERSION on older Perls\, and unfortunate adoption of the awful "use version; our $VERSION = qv(...)" meme has created enormous confusion and work for toolchain maintainers to keep things working sanely everywhere.

I fully understand that at the time\, it was done with the best of intentions and I don't say any of this to dismiss all the hard work that you've put into creating it and maintaining it. But the fact that it *has* been so much effort for you and others is a big signal to me that the design is flawed.

I *don't* think we can put the genie back in the bottle\, but I'd like to find ways to restrict what the genie is allowed to get his grubby mitts on.

-- David

[p5pRT]

From @JohnPeacock

David Golden wrote​:

With all due respect\,\, that's what I disagree with. In hindsight\, I think that version.pm should have been strictly limited to providing an interface to the Perl internals for version number conversion and comparison.

There were no internals to expose until 5.10.0 was released. You are also being far too parochial in your view; I know of at least one person who uses version.pm with RPM spec files​:

  https://rt.cpan.org/Ticket/Display.html?id=48291

though as you can see from the ticket not without their own difficulties.

Having externally available version objects\, changing UNIVERSAL​::VERSION on older Perls\, and unfortunate adoption of the awful "use version; our $VERSION = qv(...)" meme has created enormous

That meme exists only because the toolchain didn't include version.pm already (and because I was arrogant/naive enough to name it qv() in the first place). And without a version-aware UNIVERSAL​::VERSION\, it wouldn't work on older Perl's at all (since the Perl core diddles the SV's directly without any thought to overloading\, etc).

I don't want to continue to fight this protracted battle over the past and what cannot change now. I just want to move forward. Here are my proposed steps​:

1) Add S_force_package_version to toke.c and make it use scan_version instead of some other handcrafted tokenizer. I did this last night and it was trivial\, but the question is whether it should store a version object or a stringified form instead; both have advantages and disadvantages and both fail some of the new comp/package.t tests (which don't follow the regexes in any case).

2) Modify scan_version to accept a "strict" flag\, which limits the acceptable version strings to match the accepted regex. All other callers of scan_version will set this to false (thus maintaining the status quo). This will necessitate a CPAN release of course.

3) Change S_force_version to not create those weird dualvar things and strictly prefer a string form. This should be completely trivial\, since the machinery in the core already knows how to deal with going from strings to version objects when required.

These are both targeted steps and I feel confident that they are doable in a short timeframe (depending on $WORK and how much more arguing we have to do on the list\, I hope to have it done by the weekend).

Does this meet with everyone's satisfaction?

John

[p5pRT]

From @xdg

On Wed\, Dec 2\, 2009 at 6​:33 AM\, John Peacock \john\.peacock@&#8203;havurah\-software\.org wrote​:

I don't want to continue to fight this protracted battle over the past and what cannot change now.  I just want to move forward.

Agreed.

Here are my proposed steps​:

I'm not close enough to the C code to say and likely don't have the bandwidth this week to dig into it more deeply. I'll give snap reactions so take them with a grain of salt.

1) Add S_force_package_version to toke.c and make it use scan_version instead of some other handcrafted tokenizer.  I did this last night and it was trivial\, but the question is whether it should store a version object or a stringified form instead; both have advantages and disadvantages and both fail some of the new comp/package.t tests (which don't follow the regexes in any case).

And for now we would use this only for "package NAME VERSION"? And would use scan_version with the "strict" flag?

2) Modify scan_version to accept a "strict" flag\, which limits the acceptable version strings to match the accepted regex.  All other callers of scan_version will set this to false (thus maintaining the status quo).  This will necessitate a CPAN release of course.

What breakage potential does this have? e.g. old version.pm on 5.11.X\, new version.pm on old 5.8.8\, etc?

3) Change S_force_version to not create those weird dualvar things and strictly prefer a string form.  This should be completely trivial\, since the machinery in the core already knows how to deal with going from strings to version objects when required.

Seems like a good idea.

Overall\, I think I'm having a hard time assessing the proposal without knowing what the alternatives might be and the pros/cons of such alternatives.

One of the things that bugs me is that version.pm maintains duplicative code vs core. Would it make sense to make the core version scanning functions part of the public API for 5.12? And going forward\, on Perl 5.12\, have version.pm just use the core API rather than its own code?

Would that let us freeze the code in version.pm and use it just for older perls? So that if you're on Perl \< 5.12 and you install the latest\, greatest version.pm\, you get the version semantics of Perl v5.10.1. But that's it. After that\, if you want version number bug fixes\, you have to upgrade Perl\, not version.pm. For Perl 5.12\, version.pm becomes an interface for taking strings\, checking them for validity against the core API\, and then wrapping them up as objects for manipulation.

I'm just rambling at this stage\, but I'd like to do something thoughtful\, not knee-jerk. If that means "strict" package NAME VERSION isn't possible for 5.12\, then we should pull package NAME VERSION and pick this up again in 5.13.

-- David

[p5pRT]

From @JohnPeacock

David Golden wrote​:

And for now we would use this only for "package NAME VERSION"? And would use scan_version with the "strict" flag?

Yes.

What breakage potential does this have? e.g. old version.pm on 5.11.X\, new version.pm on old 5.8.8\, etc?

Close to none. And old version.pm simply won't install on 5.11.x (or 5.12.x for that matter); the core code always takes precedence. New version.pm from the forthcoming CPAN release will operate exactly as it has on all Perl releases except 5.11.x/5.12.0\, where it will do nothing (status quo).

One of the things that bugs me is that version.pm maintains duplicative code vs core. Would it make sense to make the core version scanning functions part of the public API for 5.12? And going forward\, on Perl 5.12\, have version.pm just use the core API rather than its own code?

That is exactly what is going on now (and has been since 5.10.0). The C code in version.pm's CPAN release is precisely the same C code as exists in the Perl core. I literally chop out the old block of code from util.c and read in vutil/vutil.c from the CPAN release and submit a patch (those few times when I have had to do that). The XS code takes a little more manual tweaking\, because the generated C code from CPAN contains lots of cruft that we don't want in the Perl core. But that part has rarely changed because the external interface has been quite stable.

John

[p5pRT]

From @davidnicol

On Tue\, Dec 1\, 2009 at 4​:39 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

No\, but $VERSION = "0000010101" may happen\, for the first release I do on Jan 1\, 10000 (see my replay to David).

Abigail

A.\, do you have any idea what kind of hardware you might be running on then?

-- intake\, compression\, power\, exhaust\, repeat.

[p5pRT]

From @nwc10

On Mon\, Dec 07\, 2009 at 01​:19​:58PM -0600\, David Nicol wrote​:

On Tue\, Dec 1\, 2009 at 4​:39 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

No\, but $VERSION = "0000010101" may happen\, for the first release I do on Jan 1\, 10000 (see my replay to David).

Abigail

A.\, do you have any idea what kind of hardware you might be running on then?

I doubt it. But parrot 7992.0 will be released 17 days later.

Nicholas Clark

[p5pRT]

From @abigail

On Mon\, Dec 07\, 2009 at 07​:32​:02PM +0000\, Nicholas Clark wrote​:

On Mon\, Dec 07\, 2009 at 01​:19​:58PM -0600\, David Nicol wrote​:

On Tue\, Dec 1\, 2009 at 4​:39 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

No\, but $VERSION = "0000010101" may happen\, for the first release I do on Jan 1\, 10000 (see my replay to David).

Abigail

A.\, do you have any idea what kind of hardware you might be running on then?

I'm not sure\, but it will have at least 2 floppy drives!

I doubt it. But parrot 7992.0 will be released 17 days later.

And Perl6^WRakudo will still be finished by Christmas.

Abigail

[p5pRT]

From @leonerd

On Tue\, 8 Dec 2009 09​:35​:43 +0100 Abigail \abigail@&#8203;abigail\.be wrote​:

On Mon\, Dec 07\, 2009 at 07​:32​:02PM +0000\, Nicholas Clark wrote​:

On Mon\, Dec 07\, 2009 at 01​:19​:58PM -0600\, David Nicol wrote​:

On Tue\, Dec 1\, 2009 at 4​:39 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

No\, but $VERSION = "0000010101" may happen\, for the first release I do on Jan 1\, 10000 (see my replay to David).

Abigail

A.\, do you have any idea what kind of hardware you might be running on then? ...

And Perl6^WRakudo will still be finished by Christmas.

You think they'll still celebrate Christmas by then? Perhaps they'll have to find a new joke...

-- Paul "LeoNerd" Evans

leonerd@​leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http​://www.leonerd.org.uk/

[p5pRT]

From @JohnPeacock

To update this ticket\, I have a revise plan of attack to resolve this ticket​:

1) Patch toke.c to use scan_version for `package NAME VERSION` - completed (I can send it tonight if desireable).

2) Add $version​::STRICT and $version​::LAX regexes to version.pm - I will definitely send my revised suggestions tonight (they're on the laptop).   $LAX corresponds to the existing version.pm behavior and $STRICT is a greatly reduced space of acceptable forms (as discussed already). I'm trying to write a new test that goes through all of the suggested forms and make sure that the regexes match.

3) Create common is_valid_version (suggestions for a better name appreciated) that will be shared between CPAN version.pm code and core version code. This will implement in C the regexes described above. This gets called from the toke.c patch above with the "strict" flag set and the normal version object codepath runs as "lax".

4) Release an alpha version.pm to CPAN with #2 and #3 implemented (by the weekend?).

By using is_valid_version()\, the amount of code that needs to change _now_ in the main version object code is greatly minimized. I can deal with the improvements to alpha handling later.

How does that sound? Do we have a rough schedule for drop dead date on 5.12.0???

John

[p5pRT]

From @xdg

With the recent strict/lax version numbers patch\, both .1 and 1e1 appear to work. Note that in the latter case\, it cannot be passed as a string "1e1" to UNIVERSAL​::VERSION or version->new() as it does not meet the lax rules.

I am increasingly leaning towards the view that *all* version number inputs -- including use() -- be required to pass the same 'lax' test\, but at the moment\, use() has it's own code path that is even more permissive than the 'lax' rules applied elsewhere.

Given code freeze\, that will need to wait until 5.13.

I'm closing this ticket and will open a new one regarding the need for documentation of new behaviors.

David

[p5pRT]

@xdg - Status changed from 'open' to 'resolved'

[p5pRT]

From @xdg

Reopening -- three things need to happen\, per this thread​: http​://www.nntp.perl.org/group/perl.perl5.porters/2010/01/msg155701.html

SUMMARY AND RECOMMENDATIONS​:

* 'use NAME VERSION' has loose VERSION checks that can unexpectedly pass the VERSION as an argument to import. Even if it passes the loose check\, it dies later in UNIVERSAL​::VERSION unless the 'lax' check passes. Therefore\, we should add 'lax' version checks explicitly to 'use NAME VERSION' parsing

* Three digit number strings created under a comma-radix could fail to pass the 'lax' test. Therefore\, we should always use the NV in Perl_upg_version if SvNOK is true\, without regard for SvPOK. We should probably check for it being a v-string\, first\, anyway\, as v-string has no ambiguity about how it is to be treated.

* Have version->new(undef) create a new version with "0" instead of "undef" (this should have no real effect except it won't break later if we make everything strict)

I feel pretty strongly that these changes should go into 5.12. In addition to existing patches on this topic\, 5.12 will then provide clear\, consistent treatment of version numbers through all paths. Strict and lax version number formats will be well defined\, and we will still be fairly liberal ('lax') in what we accept.

[p5pRT]

@xdg - Status changed from 'resolved' to 'open'

[p5pRT]

From @abigail

On Tue\, Dec 01\, 2009 at 05​:32​:08AM -0500\, David Golden wrote​:

On Tue\, Dec 1\, 2009 at 5​:24 AM\, Abigail \abigail@&#8203;abigail\.be wrote​:

As long as $VERSION is allowed to match /^[0-9]{10}$/\, I'm happy.

Do you *really* want leading 0 (i.e. octal) version numbers? :-)

Yes\, that means extending the life span of my version numbers with another 1000 years; I do not want to add to the Y10K problem\, I go for a Y11K problem instead.

Expect me to start bugging for $VERSION numbers matching /^[0-9]{10\,11}$/ around the year 10950.

Abigail