Bug #19017 for version: problems with 0.0.x versions

Michael_Schilli via RT wrote: Show quoted text
Hmmm, it's trickier that I thought at first glance. It's actually related to how 'use' treats terms after the module name and specifically, whether that next term looks like a specific kind of number (e.g. one starting with 0). If you make those examples above equal to 1.0.4 and 1.0.8 (without the qv() on the 'use' line), it correctly gives the message: Foo version 1.000008 (v1.0.8) required--this is only version 1.000004 (v1.0.4) at t.pl line 2. BEGIN failed--compilation aborted at t.pl line 2. (except with Perl 5.005_04, see below). IIF the term following the modulename in 'use' and 'require' look like a number, then for some values of Perl (again 5.005_04 always misfires), then the inherited Exporter::import method will internally call UNIVERSAL::VERSION on the module's behalf. However, if the leading digit is 0, the tokenizer messes with the number before passing and you get the error you originally noted. For now, the AnnoCPAN entry is wrong; I can fix that by providing an import() method to version.pm (which means I can do what I want for most values of Perl). As soon as I have something to test, I'll shoot you a note... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748

Mike Schilli via RT wrote: Show quoted text
That's a different error; if you use qv() after the 'use' line, it assumes this is supposed to be one of the @EXPORTS_OK items (to use Exporter-speak), and *not* a version comparison (which only works with bare numbers). I don't know how I am going to get around that (apart from inheriting version::import that DTRT). Show quoted text
OK, I'm on the trail of what is really going on with the original report. A while ago, I introduced code such that if the input to several of the ways that version objects could be created was a floating point number (NV), then I forced it into a string using sprintf() (since otherwise I would be dependent on the vagaries of how Perl does the conversion internally). Unfortunately, there doesn't appear to be a way to force sprintf() to produce a non-exponential representation once the number gets below 10**-5. I'm going to have to re-write the parser to handle exponential notation I'm afraid. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748

Mike Schilli via RT wrote: Show quoted text
Yes, but for some reason that I'm not remembering, I've always used NVgf (equivalent to "%g") instead. Perhaps I can just switch to NVff instead and then the question becomes what fixed length I should use (currently 9) and whether I should worry about trailing zeros on non-extended version objects. John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748

On Thu May 04 22:27:51 2006, jpeacock@rowman.com wrote: Show quoted text
I neglected to update RT with the fact that I released version-0.59_02 to CPAN on Friday with a rewrite (and new tests) to fix this issue. If you can get a chance to test it, I'd appreciate it. I'll probably release 0.60 by this weekend if I don't hear anything bad... John